Pete French wrote: >> 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.
Ah, I see; It's defined as
u_int d_priority; /* Disk priority. */
in struct g_mirror_disk but as
uint8_t md_priority; /* Disk priority. */
in struct g_mirror_metadata. Ok, 128 looks reasonable now.
> 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.
Hmm, it would seem you need "N-and-upper" and "N-and-lower", but this is
inconvenient. Your original idea is probably better.
> I'll get an initial version out and then maybe take a look at doing
> something more complex though.
signature.asc
Description: OpenPGP digital signature
