Date: Thu, 08 May 2008 14:18:23 +0100 From: Pete French <petefrench@ticketswitch.com> To: freebsd-stable@freebsd.org, ivoras@freebsd.org Subject: Re: Dreadful gmirror performance - suggested changes to 'prefer' Message-ID: <E1Ju60t-0001c3-GO@dilbert.ticketswitch.com> In-Reply-To: <fvuse6$n5h$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 > supported. 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 as possible. I'll get an initial version out and then maybe take a look at doing something more complex though. cheers, -pete.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1Ju60t-0001c3-GO>