From owner-freebsd-doc@FreeBSD.ORG Sun Jun 10 16:25:17 2012 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4B67106566C; Sun, 10 Jun 2012 16:25:17 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 5493B8FC08; Sun, 10 Jun 2012 16:25:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q5AGPACu076750; Sun, 10 Jun 2012 10:25:10 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q5AGPAT5076747; Sun, 10 Jun 2012 10:25:10 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 10 Jun 2012 10:25:10 -0600 (MDT) From: Warren Block To: Hiroki Sato In-Reply-To: <20120610.231555.975873460722378457.hrs@allbsd.org> Message-ID: References: <20120606.185023.497714372668376681.hrs@allbsd.org> <20120610.231555.975873460722378457.hrs@allbsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sun, 10 Jun 2012 10:25:10 -0600 (MDT) Cc: doc@FreeBSD.org Subject: Re: Handbook mirroring section X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 16:25:17 -0000 On Sun, 10 Jun 2012, Hiroki Sato wrote: > Warren Block wrote > in : > > 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.