Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Jun 2012 08:22:25 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Pawel Jakub Dawidek <pjd@freebsd.org>
Cc:        freebsd-hackers <freebsd-hackers@freebsd.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru>, Andriy Gapon <avg@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: [CFC/CFT] large changes in the loader(8) code
Message-ID:  <201206270822.25672.jhb@freebsd.org>
In-Reply-To: <20120626212308.GE1399@garage.freebsd.pl>
References:  <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <20120626212308.GE1399@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, June 26, 2012 5:23:08 pm Pawel Jakub Dawidek wrote:
> On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote:
> > > 4. The gptboot now searches the backup GPT header in the previous sectors,
> > > when it finds the "GEOM::" signature in the last sector. PMBR code also
> > > tries to do the same:
> > >         common/gpt.c
> > >         i386/pmbr/pmbr.s
> > 
> > GPT really wants the backup header at the last LBA.  I know you can set it, 
> > but I've interpreted that as a way to see if the primary header is correct or 
> > not. [...]
> 
> My interpretation is different: The way to verify if the header is valid
> is to check its checksum, not to check if the backup header location in
> the primary header points at the last LBA.
> 
> Of course if primary header's checksum is incorrect it is hard to trust
> that the backup header location is correct. And we need the backup
> header when the primary header is invalid...

Right, which is why this fails.

> > [...] It seems to me that GPT tables created in this fashion (inside a GEOM 
> > provider) will not work properly with partition editors for other OS's.  I'm 
> > hesitant to encourage the use of this as I do think putting GPT inside of a 
> > gmirror violates the GPT spec.
> 
> 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.  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.

My approach has been to only use gmirror with MBR so far, though I realize
that doesn't work above 2TB (until recently one had to have a hardware RAID
to get above 2TB anyway which made this last a moot point).

I won't object to patch our tools to handle this, but I think it is a really
bad idea that users will have a hard way to recover from when they are bitten
by it.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206270822.25672.jhb>