Date: Sun, 10 Jun 2012 10:25:10 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Hiroki Sato <hrs@FreeBSD.org> Cc: doc@FreeBSD.org Subject: Re: Handbook mirroring section Message-ID: <alpine.BSF.2.00.1206101011080.76685@wonkity.com> In-Reply-To: <20120610.231555.975873460722378457.hrs@allbsd.org> References: <alpine.BSF.2.00.1206052220390.10777@wonkity.com> <20120606.185023.497714372668376681.hrs@allbsd.org> <alpine.BSF.2.00.1206060454200.13150@wonkity.com> <20120610.231555.975873460722378457.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Jun 2012, Hiroki Sato wrote: > Warren Block <wblock@wonkity.com> wrote > in <alpine.BSF.2.00.1206060454200.13150@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. Agreed. This doc should point out that BIOS boots from one of the individual drives, not the mirror. > 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. It would certainly make things a lot simpler. gpart would need modification. > 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. I tried a whole-disk GPT mirror for a short time, and had no problems other than gptboot complaining about the corrupted secondary header. It was not an exhaustive test, though.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206101011080.76685>