Dreadful gmirror performance - suggested changes to 'prefer'
petefrench at ticketswitch.com
Thu May 8 13:18:25 UTC 2008
> 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.
Are you sure it isn't an 8 bit value underneath ? I know it is defined as
an int, but trying to set it to anything outside the range 0-255 results
in it wrapping round (e.g. you try making the defalt 1000 and it comes
out as 232). I havent looked in detail as *why* thats happening, but it
certainly behaves like it is 8 bits, hence my choice of default.
> - 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
I thought about that, but the priority scheme doesnt just specify one
drive, it specifies a whole set - effectively you find the highest usable
drive. Just defining one isn't sufficient, you need to have a defined
way of falling back if that one isn't active. Secondly I want to avoid
having to search the whole list event time. Currently the list of drives
is created in priority order (no matter what the balance algorithm) so
the 'prefer' algorithm simply traverses the list looking for the first
active drive. I wanted to keep that and thus simply convert the list to
a tailq so I can traverse it both ways, rather than having to seek the
whole list every time. It keeps the code as close to the current code
I'll get an initial version out and then maybe take a look at doing
something more complex though.
More information about the freebsd-stable