From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 04:23:45 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 40F4A106566C; Mon, 22 Aug 2011 04:23:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id D9B518FC15; Mon, 22 Aug 2011 04:23:44 +0000 (UTC) Received: by yib19 with SMTP id 19so3753037yib.13 for ; Sun, 21 Aug 2011 21:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FX7DjBaZkz1PWJzi1uOtI1m9IY7otd3jT+atqFKjLxA=; b=Eu4/NxPFRowtT1YOOKSX6LRGeNAi1HX92RB9QQd2iiJY6W2yNGOp27oPO7slvsZUqB HrqAgNJGq2Qb5miiRDhlO+xOBQw7CsRkfUNrZ/IltXbeknTza+BND25t7cZR9/KcaOjZ PEwVje9WGbPtLQNlPAjYePb/22YWXw9lpB708= MIME-Version: 1.0 Received: by 10.150.133.17 with SMTP id g17mr1187574ybd.272.1313987023090; Sun, 21 Aug 2011 21:23:43 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Sun, 21 Aug 2011 21:23:43 -0700 (PDT) In-Reply-To: <4E51BD0E.7040204@freebsd.org> 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> Date: Mon, 22 Aug 2011 12:23:43 +0800 X-Google-Sender-Auth: v1lkQUb05CD8rdVVPMAnyn5rHEw Message-ID: From: Adrian Chadd To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 04:23:45 -0000 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. :-) Adrian On 22 August 2011 10:21, Nathan Whitehorn wrote: > Doing it that way is really, really error-prone, because you have to gues= s > (a) whether gpart will accept certain configurations and (b) how it will > handle requests. On some schemes, partititions have to be aligned or size= d > 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 dec= ide > this, and you can act on the result at the same time you request it. Doin= g > it in userland means you need to guess, perfectly, all the time, what wil= l > happen with every input to every module, and so that you have a > fully-functional perfect simulator of all possible behaviors and states o= f > every type of partitioning that the kernel currently or may ever support. > 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 particula= r >>>>>> case, and asks about each subpartition tree separately with a big sc= ary >>>>>> dialog box. In the spirit of the autopartitioner, it makes one large= scary >>>>>> dialog, and always runs in early commit mode instead of potentially = showing >>>>>> many scary dialogs about partitions the user doesn't necessarily eve= n know >>>>>> about. This behavior could be changed, but I think is the most frien= dly for >>>>>> the case in question: namely, "I want to blow away everything and le= t 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 on >>>>> 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 va= lidate >>>> 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" >>> > >