From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 15:49:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3593C1065674 for ; Fri, 17 Feb 2012 15:49:44 +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 C74168FC1F for ; Fri, 17 Feb 2012 15:49:43 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1HFnfpR052762; Fri, 17 Feb 2012 08:49:41 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q1HFnfIL052759; Fri, 17 Feb 2012 08:49:41 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 17 Feb 2012 08:49:41 -0700 (MST) From: Warren Block To: Freddie Cash In-Reply-To: Message-ID: References: <20120217030806.GA62601@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-1653418493-1329493022=:52228" Content-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 17 Feb 2012 08:49:41 -0700 (MST) Cc: freebsd-stable@freebsd.org, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd@jdc.parodius.com, Pete French Subject: Re: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:49:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---902635197-1653418493-1329493022=:52228 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 17 Feb 2012, Freddie Cash wrote: > On Fri, Feb 17, 2012 at 3:12 AM, Pete French wrote: >>> I wasn't aware you could do that.  I was only aware that it was the >>> other way around.  That (my) misconception seems to also be relayed >>> by others such as Miroslav who said: >> >> Should this not be the recommended way of doing things even for MBR >> disks ? I have a lot of machines booting from gmirror, but we always >> do it by mirroring MBR partitions (or GPT ones). I cant see why you would >> want to do it the other way round in fact. It doesnt gain you anything >> does it ? > > The problem with mirroring partitions is that you thrash the disk > during the rebuild after replacing a failed disk. Potentially, yes. > And the more partitions you have, the worse it gets. One big mirrored partition avoids it, but then there's only one partition. (ad0p2a? Forget I mentioned that.) > If you mirror the device, then the rebuild process only has to rebuild > a single "thing". > > If you mirror 4 partitions on a device, then there will be four > simultaneous, parallel rebuild processes running, thrashing the drive > heads on both devices, killing you I/O throughput and extending the > length of the rebuild. Some queuing logic in the mirror rebuild could avoid that. I am blissfully unaware of how complicated that might be. ---902635197-1653418493-1329493022=:52228--