Page MenuHomeFreeBSD

gpart resize: respect requested size when using `-a` and `-s`
AcceptedPublic

Authored by rew on Dec 7 2020, 8:38 PM.

Details

Summary

When using the -a and -s flag, gpart resize fails to set the requested
size on a given partition when there is a partition following it and when the
resize operation is growing the size of the partition. It sets it to the maximum
available space, regardless of the size requested.

This patch calculates the maximum size that can be used, either using the
start of the next partition or the last sector of the geom as the upper limit,
whichever applies.

I've removed the offset calculation. Looking at the gpart add code, the
lower and upper boundary of a partition is calculated with the offset included
and the offset is removed after the size has been calculated. As I understand
it, when resizing, the size will be the same regardless of the offset.

PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250609

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 35238
Build 32178: arc lint + arc unit

Event Timeline

rew requested review of this revision.Dec 7 2020, 8:38 PM

Let's tag in marcel@ (author) and trasz@ (geom chops)

Not the author of this particular code, but LGTM.

This revision is now accepted and ready to land.Jan 5 2021, 2:20 AM

Hi, sorry for my silence. I was busy with other tasks, and it seems forget GEOM a bit.
I think you need to test your code with BSD scheme, AFAIR, it uses stripeoffset field.

ae@, thanks for the reply - I looked at g_part_bsd_resize and there’s no reference to using the offset field. The only field it uses is the start field. Let me know if you have any other concerns.

Maybe trasz@ will weigh in - is there anything glaring I’ve overlooked?

In D27500#638475, @rew wrote:

ae@, thanks for the reply - I looked at g_part_bsd_resize and there’s no reference to using the offset field. The only field it uses is the start field. Let me know if you have any other concerns.
Maybe trasz@ will weigh in - is there anything glaring I’ve overlooked?

  1. Create MBR
  2. Create one unaligned partition and then create BSD scheme
  3. Try to create aligned partitions in the BSD scheme, they will be unaligned regarding to whole disk.

stripeoffset field is used to determine, that original start of BSD slice is not aligned.
And you need to adjust bounds of each partition in BSD scheme to be aligned to disk's sectors for example.

  1. Create MBR
  2. Create one unaligned partition and then create BSD scheme
  3. Try to create aligned partitions in the BSD scheme, they will be unaligned regarding to whole disk.

I don't see where gpart resize comes into play in this scenario.

stripeoffset field is used to determine, that original start of BSD slice is not aligned.

I don't quite follow this statement, possible to rephrase it?

And you need to adjust bounds of each partition in BSD scheme to be aligned to disk's sectors for example.

A resize operation won't change the start sector of a partition - if a partition wasn't aligned when it was created, a resize operation won't fix it (with or without this patch). The only a thing a resize operation can do is ensure that the new size is a multiple of the requested alignment and that the new size won't extend into the next partition or past the last sector of the geom.

In D27500#638775, @rew wrote:

The only a thing a resize operation can do is ensure that the new size is a multiple of the requested alignment and that the new size won't extend into the next partition or past the last sector of the geom.

Sorry, yes the most of my message was useless.
What I was trying to explain is that stripeoffset is not useless value to just remove it.

On the image is some disk, with 4k sectors used, but 512b reported. We have BSD scheme with 2 partitions. You want to resize partition 1 to maximum accessible space and make it aligned to 4k sectorsize. If you remove stripeoffset accounting, your resize will left no free space between partitions, otherwise there will be left 3.5k free space.