9.0-RC2 - bsdinstall miscount of remaining diskspace after
partition deletion.
Nathan Whitehorn
nwhitehorn at freebsd.org
Tue Nov 22 15:44:24 UTC 2011
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
More information about the freebsd-current
mailing list