From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 13:13:19 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 AC7C8106564A; Mon, 22 Aug 2011 13:13:19 +0000 (UTC) (envelope-from nwhitehorn@banshee.munuc.org) Received: from banshee.munuc.org (cl-106.chi-02.us.sixxs.net [IPv6:2001:4978:f:69::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2958FC0A; Mon, 22 Aug 2011 13:13:19 +0000 (UTC) Received: from nwhitehorn (helo=localhost) by banshee.munuc.org with local-esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvUJa-000Mdg-Bp; Mon, 22 Aug 2011 08:13:18 -0500 Date: Mon, 22 Aug 2011 08:13:18 -0500 (CDT) From: Nathan Whitehorn X-X-Sender: nwhitehorn@banshee.munuc.org To: Adrian Chadd In-Reply-To: Message-ID: References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51B228.7030001@freebsd.org> <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> <4E51BD0E.7040204@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1464019946-260687654-1314018798=:87003" Sender: Nathan Whitehorn X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: nwhitehorn@banshee.munuc.org X-SA-Exim-Scanned: No (on banshee.munuc.org); SAEximRunCond expanded to false Cc: "freebsd-current@FreeBSD.org Current" , Marcel Moolenaar Subject: Re: Well, there goes Windows! 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: Mon, 22 Aug 2011 13:13:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1464019946-260687654-1314018798=:87003 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 22 Aug 2011, Adrian Chadd wrote: > I totally get it. > > However, an installer is user-facing (here), as well as system-facing. > As much as I understand the logic behind it, it is still going to > surprise people to find that their partition tables are modified at > any point before that final "commit". > > Linux installers manage to do it. :-) This is why there is a GIANT WARNING MESSAGE IN ALL CAPITAL LETTERS before= =20 this happens, which is only under very specific circumstances. For almost= =20 all possible modifications, it doesn't change anything until commit, as=20 suggested. -Nathan > > > On 22 August 2011 10:21, Nathan Whitehorn wrote: >> Doing it that way is really, really error-prone, because you have to gue= ss >> (a) whether gpart will accept certain configurations and (b) how it will >> handle requests. On some schemes, partititions have to be aligned or siz= ed >> in particular ways and have various limitations. Depending on the module= , >> gpart will either reject the request or silently adjust it. Letting the >> kernel handle the state means that the geom modules themselves get to de= cide >> this, and you can act on the result at the same time you request it. Doi= ng >> it in userland means you need to guess, perfectly, all the time, what wi= ll >> happen with every input to every module, and so that you have a >> fully-functional perfect simulator of all possible behaviors and states = of >> every type of partitioning that the kernel currently or may ever support= =2E >> This tends not to work well. >> -Nathan >> >> On 08/21/11 21:02, Adrian Chadd wrote: >>> >>> Honestly - if you're relying on doing anything that isn't read-only w/ >>> GEOM right until "commit", I think you're doing it wrong. >>> >>> If anything, you should write something which manipulates geom tables >>> in userland, and can have a geom database populated from the kernel. >>> All of your subsequent tools (eg stuff which creates labels, raid >>> devices, etc) should manipulate this table, not the kernel. >>> >>> Then when you're ready, you should write the updated table to disk. >>> >>> 2c, >>> >>> >>> Adrian >>> >>> On 22 August 2011 09:48, Marcel Moolenaar =A0wrote: >>>> >>>> On Aug 21, 2011, at 6:34 PM, Nathan Whitehorn wrote: >>>>>>> >>>>>>> The regular partitioning editor only commits early in this particul= ar >>>>>>> case, and asks about each subpartition tree separately with a big s= cary >>>>>>> dialog box. In the spirit of the autopartitioner, it makes one larg= e scary >>>>>>> dialog, and always runs in early commit mode instead of potentially= showing >>>>>>> many scary dialogs about partitions the user doesn't necessarily ev= en know >>>>>>> about. This behavior could be changed, but I think is the most frie= ndly for >>>>>>> the case in question: namely, "I want to blow away everything and l= et the >>>>>>> installer handle all partitioning details by itself". >>>>>> >>>>>> What about inserting a special class for doing commit/undo. The GEOM >>>>>> simply keeps all modifications in memory and 1) forgets everything o= n >>>>>> an undo operation or 2) writes all dirty sectors on a commit. This >>>>>> could be used even instead of the gpart-private support, which also >>>>>> removes the quirk for the null scheme. >>>>>> >>>>> Where would this class go? If it went below gpart (between gpart and >>>>> userland), then it seems like we would lose the ability of gpart to v= alidate >>>>> its parameters. Who would be responsible for inserting this GEOM into= the >>>>> stack? >>>> >>>> Between the disk GEOM and the gpart GEOM. The gpart utility would >>>> still interact with the GEOM is before. >>>> >>>> -- >>>> Marcel Moolenaar >>>> marcel@xcllnt.net >>>> >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>>> >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --1464019946-260687654-1314018798=:87003--