[dm-devel] StorageWorks multipath support
Lars Marowsky-Bree
lmb at suse.de
Wed Jun 15 14:13:02 UTC 2005
On 2005-06-15T16:07:40, Christophe Varoqui <christophe.varoqui at 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 at 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"
More information about the dm-devel
mailing list