From owner-freebsd-stable@FreeBSD.ORG Sat Mar 21 18:44:45 2009 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 92106106566B for ; Sat, 21 Mar 2009 18:44:45 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id 6DEC18FC1E for ; Sat, 21 Mar 2009 18:44:44 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 57CD7D006F; Sat, 21 Mar 2009 08:44:43 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 99D20153882; Sat, 21 Mar 2009 08:44:42 -1000 (HST) Date: Sat, 21 Mar 2009 08:44:42 -1000 From: Clifton Royston To: Pete French Message-ID: <20090321184440.GA29399@lava.net> Mail-Followup-To: Pete French , freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: gemor mirror and priority 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: Sat, 21 Mar 2009 18:44:45 -0000 On Fri, Mar 20, 2009 at 05:39:14PM +0000, Pete French wrote: > > I'll try it and report after the weekend :) > > It should be OK - we ran it here on the main database server until > a couple of months ago, which I went back to using vanilla 7.1 in an attempt to > try and track down a bug. I will probably continue to use the patch in > future though - it's very stable, and very useful if you haave some > kind of "homemade clustering" solution with a local and remote drive. Even if you don't, I think it's quite useful to make the *default* priority set when creating a mirror be some value which allows both higher and lower values to be specified. I hadn't known about that issue until I read the original thread here a while back.If the default were set to some mid-range value, or even to 2, for example, then at least creating a new mirror and adding drives without setting a priority would continue to behave as usual, while it would be possible to explicitly insert new components with a lower priority. (I see why one wouldn't want to change the default interpretation of existing priority values for POLA reasons.) There are lots of reasons one could want to control priorities of mirrored drives in various ways. One is to use gmirror as a long-term backup approach: mirror with three drives, periodically disconnecting one from the mirror to swap it with a fresh drive from a pool of backup drives. I haven't tried this, but it's been on my mind to mess around with soon. In this case, I would want the designated backup drive to always be lowest-priority, to ensure the mirror never accidentally started rebuilding from a newly reinserted backup. (This probably wouldn't happen anyway, but it would be nice to be sure...) -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services