|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Fri, 15 Jul 2011, NeilBrown wrote:
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.
nothing is wrong with doing something smarter than what I was proposing, I was just intending to propose a default rule that would work (just about) everywhere. I was specifically trying to counter the throught hat the method number would/should be contant as it's passed down the layers.
The proposal had been made to have each layer do the retries for the layer below it, that would avoid this stacking problem, but at the cost of potentially doing a LOT of retries without the upper level being able to limit it.
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. NeilBrownthis 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
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html