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
_______________________________________________
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
