Re: [CFC/CFT] large changes in the loader(8) code

From: Miroslav Lachman <000.fbsd_at_quip.cz>
Date: Fri, 29 Jun 2012 00:04:17 +0200
Pawel Jakub Dawidek wrote:
> On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote:
>>>
>>> All of the above is ugly, U'm afraid :(
>>
>> Indeed. The only sane way is to put the metadata in a partition of its own.
>> Every compliant OS will respect that and consequently will not scribble over
>> the data unintentionally. Any other scheme that puts valuable data in some
>> undocumented or unregistered location is violating the GPT spec right away
>> and is susceptible to being clobbered unintentionally.
>
> If the user runs:
>
> 	# gpart create -s GPT /dev/mirror/foo
>
> for me it is obvious that he wants to partition the mirror device and
> not individual disks. Because the mirror was configured earlier, do you
> expect gmirror to somehow detect that someone is writting GPT metadata
> later and magically place GPT metadata on the raw disk and move mirror's
> metadata to some magic partition? Not to mention that the mirror itself
> doesn't have to be configured on top of raw disks. And not to mention
> that the mirror may never be partitioned.
>
> If GPT in your opinion is limited only to raw disks then I guess the
> best way to fix that is to refuse to configure GPT on anything except
> raw disks (which was already proposed by Andrey?). In my opinion this is
> unacceptable, but I think this is what you are suggesting.
>
> One of the GEOM design goals was to be flexible. Let the user decide in
> what order he wants to configure various layers. How do you know that in
> every possible scenerio software mirroring should come after
> partitioning and encryption after mirroring? Why can't we provide
> flexible tools to the user and let him decide? Maybe GPT nesting
> violates standards, but why can't we support it as an extention, really?
>
> I recognize the need to warn users if they use FreeBSD-specific
> features. We do that with non-standard APIs. So how about this.
>
> Let's modify gpart(8) to print a warning if GPT is configured on
> something else than raw disk. Let's the warning say that such
> configuration is non-standard and problems are expected if the disk is
> shared between other OSes.
>
> In my opinion that's fair.
>
> With such a warning in place, I think we can allow users to decide on
> their own if they really want that or not. Then, we can also improve
> FreeBSD boot loader to play nice with FreeBSD-specific extensions.

I think this is valid point of view. FreeBSD already does things not 
supported by other OSes and I am completely fine with it - I am running 
FreeBSD on servers, not sharing anything with other OSes so I prefer 
extended FreeBSD specific features over 100% standard compliant 
behaviour crippling SW mirroring etc.

I think that our tools should support / provide all standard compliant 
(compatible) features, but let user to choose any other extended 
non-compatible features if user wants it. Even if it can be seen as 
foot shooting by somebody else.

And maybe one day our solution will be widespread and taken as a standard.

Miroslav Lachman
Received on Thu Jun 28 2012 - 20:04:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC