Well, there goes Windows!

Nathan Whitehorn nwhitehorn at freebsd.org
Mon Aug 22 13:13:19 UTC 2011

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 happens, which is only under very specific circumstances. For almost 
all possible modifications, it doesn't change anything until commit, as 

> 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"

More information about the freebsd-current mailing list