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

[John Baldwin]

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).

-- 
John Baldwin