Re: Well, there goes Windows!

  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
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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