From owner-freebsd-doc@FreeBSD.ORG Wed Jun 6 11:26:36 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 660541065672; Wed, 6 Jun 2012 11:26:36 +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 1C8428FC14; Wed, 6 Jun 2012 11:26:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q56BQYdw013312; Wed, 6 Jun 2012 05:26:34 -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 q56BQYgX013309; Wed, 6 Jun 2012 05:26:34 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 6 Jun 2012 05:26:34 -0600 (MDT) From: Warren Block To: Hiroki Sato In-Reply-To: <20120606.185023.497714372668376681.hrs@allbsd.org> Message-ID: References: <20120605.051840.668781590183332493.hrs@allbsd.org> <20120606.185023.497714372668376681.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]); Wed, 06 Jun 2012 05:26:34 -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: Wed, 06 Jun 2012 11:26:36 -0000 On Wed, 6 Jun 2012, Hiroki Sato wrote: > Warren Block wrote > in : > > wb> On Tue, 5 Jun 2012, Hiroki Sato wrote: > wb> > wb> > Warren Block wrote > wb> > in : > wb> > > wb> > wb> It's a little tricky. What do you think about having two > wb> > sections, > wb> > wb> one for how to create a standard mirror from scratch, and one for > wb> > wb> converting a single-disk system to a mirror? > wb> > > wb> > It sounds like a good idea. > wb> > wb> Here's a pass at it: > wb> > wb> http://www.wonkity.com/~wblock/mirror/book.html > wb> http://www.wonkity.com/~wblock/mirror/patch-geom-2.diff > wb> > wb> Notes: > wb> > wb> I tried to factor out common information to the introduction and the > wb> Troubleshooting section afterward. > wb> > wb> diskinfo(8) was used in place of gpart list because the disk capacity > wb> is in the first three lines, so the command line is simpler. > wb> > wb> There is no entity for gnop(8) yet, but I have one locally. > > Thanks, I will review the new version. > > BTW, do you (or anyone) know the common failure pattern when trying > to use GPT + gmirror of the whole disk? IIRC it was a metadata > corruption but I do not remember when it happens. When gmirror is used to mirror two disks, metadata goes in the last block of each. If GPT partitioning is used on the mirror, the GPT secondary partition table overwrites the mirror metadata because, by specification, GPT puts that secondary table at the end of the physical drive, rather than inside the gmirror logical device. There's no good solution. If the secondary GPT table was put inside the gmirror device, it would no longer be standards-compliant. If the mirror is created after the disk GPT partitions are created, it overwrites the secondary GPT table. The mirror will work, but the backup GPT is corrupted and /boot/gptboot shows a warning about it on each boot. The alternative is to create a mirror for each GPT partition. mirror metadata goes inside each GPT partition without problem. However, multiple mirrors are running, at least three for a minimal GPT layout of one each of freebsd-boot, freebsd-ufs, and freebsd-swap partitions, and six or more for a split-filesystem layout. If more than one of those mirrors starts to resync at the same time, it will (may?) thrash the drive. The gmirror resync code could have a lock to prevent more than one resync at a time. At present, I don't know if it does, but doubt it. If gmirror could keep and locate metadata in a special GPT partition, whole-disk GPT mirrors would be possible. That might even be GEOM-compatible, with the label code detecting that partition and pointing the mirror code to it.