From owner-freebsd-current@FreeBSD.ORG Tue Nov 22 15:44:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F22B11065672; Tue, 22 Nov 2011 15:44:23 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id C301E8FC16; Tue, 22 Nov 2011 15:44:23 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LV200M0UJPY8800@smtpauth2.wiscmail.wisc.edu>; Tue, 22 Nov 2011 09:44:23 -0600 (CST) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LV200HHWJPOYO10@smtpauth2.wiscmail.wisc.edu>; Tue, 22 Nov 2011 09:44:12 -0600 (CST) Date: Tue, 22 Nov 2011 09:44:11 -0600 From: Nathan Whitehorn In-reply-to: <201111220846.58453.jhb@freebsd.org> To: John Baldwin Message-id: <4ECBC34B.5000303@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.11.22.153314, SenderIP=128.104.160.176 References: <201111211252.35193.jhb@freebsd.org> <4ECA92E8.2060904@freebsd.org> <201111220846.58453.jhb@freebsd.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.22) Gecko/20110913 Thunderbird/3.1.14 Cc: nevtic@tx.net, freebsd-current@freebsd.org Subject: Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 15:44:24 -0000 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