gpart sizes way off

[Kris Moore]

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