On Thu, 14 Jul 2011 21:58:46 -0700 (PDT) david@xxxxxxx wrote:
On Thu, 14 Jul 2011, Chris Mason wrote:
Excerpts from Ric Wheeler's message of 2011-07-14 02:57:54 -0400:On 07/14/2011 07:38 AM, NeilBrown wrote:On Thu, 14 Jul 2011 07:02:22 +0100 Ric Wheeler<rwheeler@xxxxxxxxxx> wrote:
I would suggest that each layer take the value it's give, do an integer
division by the number of values that layer supports, using the modulo
value for that layer and pass the rest of the result down to the next
layer.
I, on the other hand, would suggest that each layer be given the freedom, and
the responsibility, to do whatever it thinks is most appropriate.
This would probably involved checking the lower levels to see how many
strategies each has, and doing some appropriate arithmetic depending on how
it combines those devices.
One problem here is the assumption that the lower levels don't change, and we--
know that not to be the case.
However this is already a problem. It is entirely possible that the request
size parameters of devices can change at any moment, even while a request is
in-flight ... though we try to avoid that or work around it.
The sort of dependencies that we see forming here would probably just make
the problem worse.
Not sure what to do about it though.... maybe just hope it isn't a problem.
NeilBrown
this works for just trying values until you get the error that tells you
there are no more options.
things can get very 'intersesting' if the different options below you have
different number of options (say a raid1 across a raid5 and a single disk)
but I can't think of any good way to figure this out and assemble a
sane order without doing an exaustive search down to find the number of
options for each layer (and since this can be different for different
blocks, you would have to do this each time you invoked this option)
David Lang