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 this happens, which is only under very specific circumstances. For almost all possible modifications, it doesn't change anything until commit, as suggested. -Nathan > > > On 22 August 2011 10:21, Nathan Whitehorn <nwhitehorn_at_freebsd.org> wrote: >> Doing it that way is really, really error-prone, because you have to guess >> (a) whether gpart will accept certain configurations and (b) how it will >> handle requests. On some schemes, partititions have to be aligned or sized >> 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 decide >> this, and you can act on the result at the same time you request it. Doing >> it in userland means you need to guess, perfectly, all the time, what will >> 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. >> 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_at_xcllnt.net> wrote: >>>> >>>> On Aug 21, 2011, at 6:34 PM, Nathan Whitehorn wrote: >>>>>>> >>>>>>> The regular partitioning editor only commits early in this particular >>>>>>> case, and asks about each subpartition tree separately with a big scary >>>>>>> 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 even know >>>>>>> about. This behavior could be changed, but I think is the most friendly for >>>>>>> the case in question: namely, "I want to blow away everything and let 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 validate >>>>> 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_at_xcllnt.net >>>> >>>> >>>> _______________________________________________ >>>> freebsd-current_at_freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe_at_freebsd.org" >>>> >> >> > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Mon Aug 22 2011 - 11:13:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:17 UTC