> > 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. > 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 ? Performance is definitely not an issue there. Reliability is, and a simple API is the key to reliability. > (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. > 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.