On 2004-11-02T00:03:01, christophe varoqui <christophe.varoqui@xxxxxxx> wrote: > What problem do we try to solve here ? Planned outages, like controler > restart or firmware upgrades. Yes. > May be even the queued io threshold wouldn't be needed : let's just fail > as soon as kernel memory is exhausted or userspace fed timer is elapsed. > > Eventually, fail_if_no_path can be emulated by setting the timer to 0. This would also work for me. > > Messages: [dmsetup message <devname> <sector> <message>] > > disable_group / enable_group - toggle PG priority > > Disabled PGs are only used after all paths in enabled PGs have failed. > > fail_path / reinstate_path - toggle path status > > > I don't quite see the benefits of PG disabling feature. > > As far as I can see, all it brings is permiting kernel code to change > the maps, which seems like enabling policies in the kernel : from > userspace, we have the same effect by instanciating the PG at the tail > of the params string. 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. (So that user-space can switch back after a timeout.) > I won't touch kernel code for now, but I'm most interested in a plugin > that do a START_STOP followed by forcing a scsi rescan on all the path > of the PG. That is what is needed for StorageWorks controlers in > multibus mode. Is the rescan needed? Multipath should be below the partitioning (kpartx). As soon as the block device is activated using the START_STOP, the access should succeed. Sincerely, Lars Marowsky-Brée <lmb@xxxxxxx> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX AG - A Novell company