freebsd stable - May 2008 - Dreadful gmirror performance - suggested changes to 'prefer'

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 people
as regards the priority system in the 'prefer' balancing method.

Just to recap, creating a gmirror creates the first device with priority
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 mirror
with a local disc, subsequently add a remote disc, but then set the mirror
up to prefer the local drive.

I am thinking of a couple of changes - the first being the patch prroposed
from Andrew Snow which would create the mirror with the priority at something
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.

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
balance
algorithm changed on the fly, this lets you change which of the drives
is preferred in an existing installationg. This is precisely what you need
when switching between two machines so that the local and remote drives
become reversed.

I havent looked at the code in detail, but I can't see that it would be too
difficult. What do people think ?

-pete.

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 people
> as regards the priority system in the 'prefer' balancing method.
> 
> Just to recap, creating a gmirror creates the first device with priority
> 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
mirror
> with a local disc, subsequently add a remote disc, but then set the mirror
> up to prefer the local drive.
Ok.
> I am thinking of a couple of changes - the first being the patch prroposed
> from Andrew Snow which would create the mirror with the priority at
something
> 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.
> 
> 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 balance
> algorithm changed on the fly, this lets you change which of the drives
> is preferred in an existing installationg. This is precisely what you need
> when switching between two machines so that the local and remote drives
> become reversed.
> 
> 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080508/18de25df/signature.pgp