On 2004-11-02T17:49:12, christophe.varoqui@xxxxxxx wrote: > > Sort of. However the kernel definetely needs an additional way to switch > > PGs w/o failing all paths in one, and for user-space to notice that this > > has occured. > I still can't see why it is needed : what's wrong with trying and fail on all > paths in a path group because trying the next PG ? Because it's wrong? Something may have caused a switch-over to the other PG. (Something being an administrative intervention or some program on the same or even another node, or the device itself due to a rolling firmware update.) The paths are _not_ failed. It's just that we have switched to the other priority group. Failing the paths is _wrong_. We _could_ force a failback to the PG if we found that we had no other path in the other PG (because all of them have failed, for example.) A PG not being active is _distinct_ from a PG having no healthy paths. If and when to coordinate the switch-back to the default priority group is a user-space issue. > Performance is definitely not an issue there. Reliability is, and a > simple API is the key to reliability. Make everything as simple as possible, but no simpler. > the rescan is not needed per-se, but the device size should be updated > after the START_STOP because the initial READ CAPACITY failed on boot. > I would guess rescan is the easiest way to do that. Ok, that's a good point. Sincerely, Lars Marowsky-Brée <lmb@xxxxxxx> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX AG - A Novell company