[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 2004-11-02T00:03:01, christophe varoqui <christophe varoqui free fr> 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 suse de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]