[CFC/CFT] large changes in the loader(8) code
John Baldwin
jhb at freebsd.org
Wed Jun 27 17:30:56 UTC 2012
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
More information about the freebsd-current
mailing list