Date: Mon, 20 Jun 2011 13:40:33 -0400 From: Kris Moore <kris@pcbsd.org> To: freebsd-geom@FreeBSD.ORG Subject: gpart sizes way off Message-ID: <4DFF8611.4090705@pcbsd.org>
next in thread | raw e-mail | index | archive | help
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
There *should* be enough space for the last partition, but take a look
what actually happened on disk:
# gpart show ada0s2
=> 0 210534400 ada0s2 BSD (100G)
0 5933056 1 freebsd-ufs (2.8G)
5933056 4880384 2 freebsd-swap (2.3G)
10813440 5933056 4 freebsd-ufs (2.8G)
16746496 193787904 - free - (92G)
I'm unsure why 2048M is getting bumped up to 2.8G, same with 1534M ->
2.3G, but of course that explains why the last partition is failing.
Here's the output of "gpart show ada0" for kicks:
=> 63 419430337 ada0 MBR (200G)
63 1985 - free - (992k)
2048 102400000 1 linux-data (48G)
102402048 210534400 2 freebsd (100G)
312936448 106493952 3 linux-data (50G)
--
Kris Moore
PC-BSD Software
iXsystems
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DFF8611.4090705>