Date: Mon, 22 Aug 2011 08:13:18 -0500 (CDT) From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-current@FreeBSD.org Current" <freebsd-current@freebsd.org>, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: Well, there goes Windows! Message-ID: <alpine.BSF.2.00.1108220811160.87003@banshee.munuc.org> In-Reply-To: <CAJ-Vmo=tBaU2ssDZOHs344ri5-UTiSQasbt4bcbZGWUDM3HkPQ@mail.gmail.com> References: <CAGH67wRFP9nFQLr0Gh-h4rKWrndZSy=6Q%2BKLC_U5Fg4RD%2BJMCw@mail.gmail.com> <4E4DB9A7.4040404@freebsd.org> <CAGH67wQoXOju3=OTh%2B6JoKLxkp7Vzqu8vg%2BO9X=DPXB5EkBJtQ@mail.gmail.com> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <C429B7D4-08DD-4A86-BC4E-07B29B755736@xcllnt.net> <4E51B228.7030001@freebsd.org> <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> <CAJ-VmomU77Afb_e5sAPdKb3en8Z%2B-w1E2G4JfLyfGXrQtiA3_Q@mail.gmail.com> <4E51BD0E.7040204@freebsd.org> <CAJ-Vmo=tBaU2ssDZOHs344ri5-UTiSQasbt4bcbZGWUDM3HkPQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <nwhitehorn@freebsd.org> 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<marcel@xcllnt.net> =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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1108220811160.87003>