From owner-freebsd-doc@FreeBSD.ORG Mon Jun 4 13:45:28 2012 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90CD61065674; Mon, 4 Jun 2012 13:45:28 +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 5F1498FC12; Mon, 4 Jun 2012 13:45:28 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q54DjLtm098130; Mon, 4 Jun 2012 07:45:21 -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 q54DjLvj098127; Mon, 4 Jun 2012 07:45:21 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 4 Jun 2012 07:45:21 -0600 (MDT) From: Warren Block To: Hiroki Sato In-Reply-To: <20120604.182331.536549548943660058.hrs@allbsd.org> Message-ID: References: <20120604.182331.536549548943660058.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]); Mon, 04 Jun 2012 07:45:21 -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: Mon, 04 Jun 2012 13:45:28 -0000 On Mon, 4 Jun 2012, Hiroki Sato wrote: > Hi Warren, > > Warren Block wrote > in : > > wb> On Thu, 17 May 2012, Warren Block wrote: > wb> > wb> > Summary: Handbook mirror example broken, new rewrite here, feedback > wb> > desired before commit. > wb> > wb> Updated: > wb> > wb> http://www.wonkity.com/~wblock/mirror/book.html > wb> http://www.wonkity.com/~wblock/mirror/geom-chapter.diff > wb> > wb> Changes include aligning partitions to 4K and some additional detail. > > I tried to rewrite to use the system drive and a new one based on > your patch and a material which I used for an in-house training: Thank you--I was just working on this again a couple of nights ago. > http://people.allbsd.org/~hrs/FreeBSD/geom-mirror.html > http://people.allbsd.org/~hrs/FreeBSD/geom-chapter.20120604-1.diff This procedure works well when the new drive's capacity is no larger than the old drive's capacity. The problem I had was when the new drive was larger than the old drive. gmirror creates a mirror on the new, larger drive using the full space available (1T). The old drive (250G, say) can't be inserted in this mirror because it's not large enough. I banged my head against this several ways without success. The only way to really do it currently is to make a 250G partition on the new drive and create the mirror in that. It would work with GPT, except then there is the problem of boot partitions, and whether to mirror those, and possibly converting from the layout on the old drive. Given the rate of change in drives and the age of many solidly-running FreeBSD systems, it seems to me that a lot of users will face the problem of finding a new drive that is no larger than the old. I may be alone in that, though. One solution would be an option to gmirror(8) to arbitrarily limit the size of the mirror created. 'gmirror label -v -c 250g gm0 /dev/ada1', for example (-c for capacity). Should be an easy mod, gmirror already takes the min for capacity when the mirror is created with multiple drives. A new capacity parameter would just be another number in that list. But, at present, there is no such option in gmirror. So this procedure would require a big warning: "The new drive must be no larger than the old one, not even one block." And that would need to be explained. > I think the most difficult part of this procedure is copying the > partition table, but is this version still difficult for the average > user? > > I intentionally removed labeling and alignment handling because I > feel they are rather complex when explaining how to convert a > single-disk system to one with a mirrored disk containing the exactly > same layout and data, though I fully agree that they are also useful > and important. At least, labels of "alpha" and "beta" would be > inefficient because "gmirror status" does not show the labels as the > provider names, and gmirror member disks are recognized even if > /dev/ada0 is moved to /dev/ada6, for example. Interesting! I did not know gmirror was relocatable, although it seems a little obvious now. Yes, that makes the labels unnecessary. (Side note: on 9.x, at least the way I've been creating them, gmirror status does show drive labels!) Alignment, well I can see where it might be considered beyond the scope of this particular article. If it came to that, removing the explanation but leaving the -a4k options would be a way to simplify it yet still not let the user down. One other note: "mymirror0" was used as the mirror name to suggest that it was a user-created name rather than something the system created.