Date: Thu, 08 May 2008 14:41:41 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-stable@freebsd.org Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' Message-ID: <fvuse6$n5h$1@ger.gmane.org> In-Reply-To: <E1Ju4Qm-0005iL-7C@dilbert.ticketswitch.com> References: <E1Ju4Qm-0005iL-7C@dilbert.ticketswitch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fvuse6$n5h$1>