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

From: Pawel Jakub Dawidek <pjd_at_FreeBSD.org>
Date: Fri, 29 Jun 2012 01:07:26 +0200
On Thu, Jun 28, 2012 at 02:54:43PM -0700, Marcel Moolenaar wrote:
> On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote:
> > Or are you suggesting to
> > convince all BIOS vendors to include the ability to boot from some kind
> > of FreeBSD private partitioning scheme (not MBR as it is not
> > suitable, not GPT as you are not OK to use it on a gmirror)?
> 
> I would be having less problems if the mirroring didn't force the backup
> GPT header in anything but the last sector. [...]

GPT backup header is placed in the last sector of the mirror device,
just like the user asked. Gmirror doesn't force anything. User decides
to put GPT partitioning on the mirror device instead of raw disk.
Gmirror doesn't even know and doesn't have to know how the user uses
data area on the mirror device.

> [...] If the metadata was somewhere
> else, then we wouldn't need to kluge various places to deal with the
> ambiguity and visible interoperability problems of the various tools and
> OSes. [...]

Where is "somewhere else", exactly?

If somewhere else on this disk, then where? At the begining of the disk?
Then you would complain that it keeps metadata where the primary header
should be located and also MBR metadata, BSDlabel metadata, etc.
Somewhere in the middle of the disk? Some future GPTng may want to use
the same spot, but also gmirror-unaware boot loader will see corrupted
data (shifted by one sector). Come on...

If somewhere else is not on this disk, then I'm sorry, but this is
totally impractical. Disks are the place you store stuff. In 99% of the
cases there is no other place to store it, but the disk itself. Should
we ask users to use additional disk to keep mirror's metadata?

> [...] Thus, it's not that I object to the mirroring per se, just to the
> mirroring as it is currently implemented with gmirror.

Do you know software RAID (>=1) or volume manager that doesn't keep
metadata on component disks?

PS. We are discussing two totally different things here:
1. Is placing GPT on anything but raw disk violates the spec? I can
   agree that it does and I'm happy with gpart(8) growing a warning.
2. How to do software mirroring. Besides trying really hard I'm not sure
   what alternative are you proposing. Could you be more specific and
   describe how gmirror should be implemented in your opinion?

> > What about multipathing? In case the disk is attached via two paths but
> > multipath is not enabled, the OS sees the same disk (and the same
> > identical unique disk identifier) multiple times. Is this a violation
> > of the spec too?
> 
> It's the same disk, isn't it? The OS can actually use the property
> of the ID to infer that it has already seen this disk and not create
> multiple device nodes.

You cannot trust some id that is found on disk to be unique, as all
your assumptions break when the user decides to dd(1)-copy content of
this disk to another disk, for example.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://tupytaj.pl

Received on Thu Jun 28 2012 - 21:09:33 UTC

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