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

Reply via email to