Well, there goes Windows!

[Nathan Whitehorn]

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