Date: Tue, 22 Nov 2011 09:44:11 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: nevtic@tx.net, freebsd-current@freebsd.org Subject: Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion. Message-ID: <4ECBC34B.5000303@freebsd.org> In-Reply-To: <201111220846.58453.jhb@freebsd.org> References: <alpine.BSF.2.00.1111181304250.3186@area51.tx.net> <201111211252.35193.jhb@freebsd.org> <4ECA92E8.2060904@freebsd.org> <201111220846.58453.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ECBC34B.5000303>