Handbook mirroring section
Hiroki Sato
hrs at FreeBSD.org
Sun Jun 10 14:35:40 UTC 2012
Warren Block <wblock at wonkity.com> wrote
in <alpine.BSF.2.00.1206060454200.13150 at wonkity.com>:
wb> On Wed, 6 Jun 2012, Hiroki Sato wrote:
wb> > BTW, do you (or anyone) know the common failure pattern when trying
wb> > to use GPT + gmirror of the whole disk? IIRC it was a metadata
wb> > corruption but I do not remember when it happens.
wb>
wb> When gmirror is used to mirror two disks, metadata goes in the last
wb> block of each. If GPT partitioning is used on the mirror, the GPT
wb> secondary partition table overwrites the mirror metadata because, by
wb> specification, GPT puts that secondary table at the end of the
wb> physical drive, rather than inside the gmirror logical device.
I think the interpretation that "GPT specification says the backup
header must be at the last LBA of the *physical* disk" is just making
things too harder. The problem is that BIOS and the loader does not
support a gmirror logical volume, and the incompletely-configured
volume is recognized for a short time during a boot due to it.
The location of the backup header is recorded in the Backup LBA field
in the primary header, so everything will work fine as long as the
pre-boot programs support it and the primary header is not corrupted.
I do not think this situation is against standards conformance though
it is suboptimal. If we can teach GEOM to BIOS and/or UEFI it would
be the best, but it is not likely.
What I want to know is whether there are some practical difficulties
when we apply the whole-disk mirroring procedure for MBR to a
GPT-based system. Overwrite of the last LBA should not happen if
FreeBSD is the only one system on the disk. One common failure
scenario is when the primary header is corrupted. If there are more,
I want to know it.
-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-doc/attachments/20120610/f754bd37/attachment.sig>
More information about the freebsd-doc
mailing list