Re: StorageWorks multipath support

[Lars Marowsky-Bree <lmb@suse.de>]

On 2005-06-15T16:07:40, Christophe Varoqui <christophe.varoqui@free.fr> wrote:

> > Well, before, those paths were simply kept as "active" / "healthy" (and
> > from the point of view of the kernel code they are, just that the PG
> > they are in might not be enabled).
> > 
> Mmm, not anymore.
> 
> It was true till 0.4.4, but in HEAD there are patches to implement to proactive DM-failing of checker-failed paths. This was a request from Tran if I remember.

The emc_clariion checker considers the "ghost" paths to be healthy
because of that. (Which is true: they haven't failed, they are just
passive.)

That failed paths are not proactively failed is an orthogonal issue, and
a change I like ;-)

> > BTW, backporting uevent is a bit more annoying then I thought. How about
> > a way to manually prod the daemon? That might be useful in general, for
> > example if a hotplug event was lost due to whatever reason...
> > 
> Too bad.
> 
> Can you elaborate on what you have in mind ?

Well, basically I'd like it if a SIGHUP would still cause the daemon to
reload the configuration and rescan the mappings. (Which is a common use
of SIGHUP.) Then we'd get the best of both worlds, we could re-trigger
it on the old dists and use the more efficient uevent on newer kernels.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"