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

On 11/22/11 07:46, John Baldwin wrote:
> On Monday, November 21, 2011 1:05:28 pm Nathan Whitehorn wrote:
>> 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.
> I think you would need to not commit to as many details up front and figure
> out the names and exact sizes when doing the commit if you wanted to support
> this (i.e. you know the user wants a partition of 4GB, another one of 2GB,
> and one for "rest of disk", and you only bind those to specific names and
> exact sizes on the final commit).
>

Exactly. It requires a fundamental rewrite of the code -- something also 
fraught with peril because some partition schemes (VTOC8 comes to mind) 
have ... interesting ... rules that the partitioner would need to know 
about.
-Nathan