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

On Wednesday, June 27, 2012 10:08:17 am Pawel Jakub Dawidek wrote:
> On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote:
> > > I don't think so. Most common case is to configure partitions on top of
> > > a mirror. Mirroring partitions is less common. Mostly because of
> > > hardware RAIDs being popular. You don't expect hardware RAID vendor to
> > > mirror partitions. Partition editors for other OS's won't work, but only
> > > because they don't support gmirror. If they wouldn't recognize and
> > > support some hardware (or pseudo-hardware) RAIDs there will be the same
> > > problem.
> > 
> > Hardware RAIDs hide the metadata from the disk that the BIOS (and disk
> > editors) see.  Thus, putting a GPT on a hardware RAID volume works fine
> > as the logical volume is always seen by all OS's consistently. [...]
> 
> Only if you won't connect this disk to a different controller.

Yes, but people do not expect to be able to yank a hardware RAID drive out and 
hook it up to a "raw" disk controller and have it work.

> > [...] The same
> > is even true of the "software" RAID that graid supports since the metadata
> > is defined by the vendor and thus the logical volume is always seen other
> > OS's consistently.
> 
> But is it seen without metadata by the boot loader?

Yes.  The logical volume shows up as a BIOS disk device.

> What I'm trying to say is that it is fair to expect from the user to not
> use gmirror-configured disk on different OS. If the user wants to use
> this disk in different OS then he has to use format that is recognized
> by both.
> 
> Because gmirror is supported by FreeBSD we should improve the support by
> teaching boot loader about it. Pretending gmirror is special and
> recommending to mirror partitions with it instead of raw disks is not
> the solution.
> 
> I really can't see how gmirror is different in this regard from any
> other software RAID or volume manager. If you try to use disk that
> contains unrecognized metadata the behaviour is undefined (but hopefully
> not a panic).

It is not gmirror I am complaining about, it is the non-standard use of GPT.
Note that gmirror + MBR works fine without violating what little standard 
there is for the MBR.  Using a dedicated GPT partition to hold the gmirrror 
metadata would work with GPT (but be a good bit harder to work with in terms 
of GEOM I realize).

But as I said, I won't object to these patches.

-- 
John Baldwin