gpart sizes way off

[Alexander Motin]

On 20.06.2011 22:36, Xin LI wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 06/20/11 11:13, Andrey V. Elsukov wrote:
>> On 20.06.2011 21:40, Kris Moore wrote:
>>>
>>> Not sure if this has been reported, apologies if I'm late to noticing this.
>>>
>>> I'm not sure if something has changed in the past few weeks on CURRENT
>>> to cause this, or if we are just noticing it for the first time, but
>>> when doing installs and using "gpart add" for creating partitions on a
>>> 2nd MBR slice, the sizes we are giving it are WAY off what actually is
>>> allocated. For example:
>>>
>>> # gpart add -s 2048M -t freebsd-ufs -i 1 /dev/ada0s2
>>> ada0s2a added
>>> # gpart add -s 1534M -t freebsd-swap -i 2 /dev/ada0s2
>>> ada0s2b added
>>> # gpart add -s 2048M -t freebsd-ufs -i 4 /dev/ada0s2
>>> ada0s2d added
>>> # gpart add -s 97165M -t freebsd-ufs -i 5 /dev/ada0s2
>>> gpart: autofill: No space left on device
>>
>> Which revision do you use?
>> Also, please, show the output of `gpart list` and `geom disk list`.
>
> I can reproduce the problem on -CURRENT however the cause seems to be a
> weird one.
>
> Attached is a (workaround?) for this issue.
>
> The revision 201645 seems to have exposed this problem -- when there is
> no stripesize, the part class exposes the absolute offset when
> stripesize == 0, while what gpart really want to do is to align against
> a stripe, where the stripesize is not really meaningful here.
>
> Alexander, would you please help to review my patch?

I think it is also not good. It will ignore useful absolute offset in 
case if user specified wanted alignment on command line. Proper fix I 
think would be in adding there:
	offset %= alignment;

-- 
Alexander Motin