From owner-freebsd-stable@FreeBSD.ORG Thu May 8 12:41:55 2008 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 08023106566C for ; Thu, 8 May 2008 12:41:55 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 836688FC1E for ; Thu, 8 May 2008 12:41:54 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ju5RX-0000eT-4O for freebsd-stable@freebsd.org; Thu, 08 May 2008 12:41:51 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 May 2008 12:41:51 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 May 2008 12:41:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 08 May 2008 14:41:41 +0200 Lines: 81 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig435046F627FA2D6A2EFA0B8D" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.12 (X11/20080227) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' 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: Thu, 08 May 2008 12:41:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig435046F627FA2D6A2EFA0B8D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pete French wrote: > I am just looking at this again, and am in a bit of a mood > for writing some patches, so I wanted to run the following idea past pe= ople > as regards the priority system in the 'prefer' balancing method. >=20 > Just to recap, creating a gmirror creates the first device with priorit= y > zero. Adding extra devices lets you set their priorities, but you cant > set negative values. The upshot is that the first device in the mirror > always has the lowest priority - so you cannot (for example) create a m= irror > with a local disc, subsequently add a remote disc, but then set the mir= ror > up to prefer the local drive. Ok. > I am thinking of a couple of changes - the first being the patch prropo= sed > from Andrew Snow which would create the mirror with the priority at som= ething > other than zero (128 would be my preference) so that extra devices can = be > inserted both above and below it. This solves the problem for newly > created mirrors as the priority can then be set as appropiate. >=20 > The other change I wanted to make was to add a second 'prefer' mode to = gmirror > though - one which would prefer the *lowest* priority instead of the > highest priority. I would probably rename the existing mode to 'prefer-= high' > (keeping 'prefer' as a synonym for backward compatibility) and add > a 'prefer-low' as well. As an existing gmirror can have it's load balan= ce > algorithm changed on the fly, this lets you change which of the drives > is preferred in an existing installationg. This is precisely what you n= eed > when switching between two machines so that the local and remote drives= > become reversed. >=20 > I havent looked at the code in detail, but I can't see that it would be= too > difficult. What do people think ? Couple of ideas: - Don't use "128" as the default since it will lead people to think there's an 8-bit quantity behind the setting (and subsequently develop weird theories about how the setting works), when it isn't so. Use 100 or 1000. - Why not go all the way and make another argument or a switch that will specify exactly which drive to prefer, so you could say "prefer N", where N is any drive / component, not only the one with lowest/highest priority? This is slightly more complex and will probably require an addition to the metadata (which isn't complicated but you have to be careful) and a workaround so the old semantics of the "plain" setting is supported. --------------enig435046F627FA2D6A2EFA0B8D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIIvUFldnAQVacBcgRAr5+AJ0ShVReGJFnWvxI5obV/HlligMEugCfVjNw a1k3Y2BnV1dsNb3j9UyrNCI= =bmCL -----END PGP SIGNATURE----- --------------enig435046F627FA2D6A2EFA0B8D--