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 <nwhiteh...@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<mar...@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
mar...@xcllnt.net
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
