On 2004-11-07T19:40:45, Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > > I've had to think about this one a bit. But there's also a flaw in the > > bypassed logic here (at least as implemented now, unless you got some > > patch I've not yet seen). Namely, we don't ever reset it. > We rely on userspace to reset it. Yes, the problem I was hinting at is that this does not in fact protect against 'automatic' PG switches, because as soon as a path from the higher priority non-bypassed PG becomes available again it would immediately switch. Of course this can also be solved by ensuring that user-space first takes care of the bypassed flags before reinstating a path, but under very much constructed timings and events, that might still fail. (ie, PG is bypassed by the kernel exactly in between user-space checking the flags and the path being reinstated). > > So yes, we probably ought to remember that we switched PGs, but probably > > also should clear that flag after some IO has succeeded once w/o causing > > a PG switch over. > At the moment, I still prefer to leave that to userspace. > (On the grounds that there's policy involved here - how much I/O or > elapsed time? Depends on the failure mode.) Hm. Ok. Probably these corner-cases don't matter much. > > Well there might be the reason to set them on the initial table load to > > get us off started correctly. > To set the number of the PG to be used first, like you suggested. Yes, that's what I meant. > That all seems to make for a coherent approach again, cleaner to use > than before, though slightly more complex internally currently. Ok, great. Christophe, any particular wishes on how to implement this in the multipath-tools? Would you want an additional helper to call to answer the question of which PG should be active or bypassed first? Sincerely, Lars Marowsky-Brée <lmb@xxxxxxx> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business