9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.

[Nathan Whitehorn]

On 11/21/11 11:52, John Baldwin wrote:
> On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote:
>> On 11/18/11 17:09, nevtic at tx.net wrote:
>>>
>>> If you are performating a manual partion in 9.0-RC2 bsdinstall and you
>>> delete any created partition except the most recently created one, the
>>> total remaining space will be miscalculated.  Reproducable as shown
>>> below.
>>>
>>> Workaround:  if you delete a partition that is not the last partition
>>> that was created, delete all partitions created after that partition
>>> before continuing.  Order does not seem to be important.
>>>
>>> The results are similar with other hard drive sizes, with the i386 or
>>> amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go
>>> back and check install discs prior to RC1)
>>>
>>> Reproducing the miscount:
>>>
>>> A 114 GB drive is used for this example:
>>>
>>>    Select Manual Partitioning
>>>
>>>    Perform the first Create on the drive and select GPT
>>>
>>>    Creating the first partition:  "Add Partition" "size" shows 114GB
>>>
>>>      Change size to 4GB, set mountpoint to  /  and tab to OK
>>>        (agree to the boot partition creation)
>>>
>>>    Create a second partition: "Add Partition" "size" shows 110GB
>>>
>>>      Adjust size to 10GB, set mountpoint to  /usr and tab to OK
>>>
>>>    Create a third partition: "Add Partition" "size" shows 100GB
>>>
>>>      Adjust size to 20GB, set mountpoint to /var, and tab to OK
>>>
>>>    Create a 4th partition: "size" shows 80GB remaining
>>>
>>>      Adjust size to 40GB, set mountpoint to /data,  and tab to OK.
>>>
>>> There is 40 GB remaining on the drive.  Now change the size of /var.
>>> First, delete the currently configured /var partition.
>>>
>>> In the Partition Editor, adding up all the lines on the screen shows
>>> 54GB (plus a 64K boot) as allocated, so there should now be 60GB
>>> remaining.  But the deleted /var space has not been added back into
>>> the total.
>>>
>>> Select Create again: "Add Partition" "size" shows 40GB
>>>
>>>     Adjust size to 30GB, set mountpoint as /var, tab to OK
>>>
>>> A subsequent "Create" will show that 20GB is remaining, rather than
>>> the actual remaining 30GB.  Selecting any size 20GB or larger for
>>> /home will give you a 20GB partition, and then an additional create
>>> will show the 10GB.
>>
>> This isn't a bug. The partitions are laid out on disk already, and,
>> because you deleted one in the middle, the largest *contiguous* block of
>> free space is 20GB, which is what is shown and the maximum it is
>> possible to create. That's why you can make one 20 GB partition and one
>> 10 GB partition, but not a single 30 GB one.
>
> Except that this is not intuitive.  If I'm laying out a disk and haven't
> committed the changes yet, it should be possible to do things like resize
> an existing partition, or have the installer realize that if you delete
> one partition the other partitions that are pending should just "move up"
> to maximize free space automatically.  I ran into this when first trying
> the new installer last week where you could not modify a pending partition's
> size which I found non-intuitive.
>

There doesn't seem to be an easy solution though. Not laying them out on 
disk is extremely fragile: the installer needs to know tons of tiny 
details about the partition schemes (alignment constraints, partition 
numbering/lettering, available space after the header, the list is very 
long) or it will break. One simple example is that whether a partition 
is ad0s1 or ad0s3 depends on its order on the disk (or in the partition 
table anyway). If I have an ad0s2 and s3, and delete the s2, should the 
new partition be s2 or s4? That depends on a lot of things the installer 
can't easily know about, and that even if it could, simulating which 
would be dangerous.
-Nathan