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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206101011080.76685>