[dm-devel] 2.6.10-rc1-udm1: multipath work in progress

[christophe.varoqui at free.fr]

> > 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.