Multipath architecture.

Multipath architecture.

[Daniel Stodden]

Hi.

Can someone spare a little time to help me understand the multipath
utility and daemon a little better?

I read myself through the available documentation. The refbook says that
it's multipath who's creating maps, and multipathd responsible for path
checking.

Running multipath (at least the version 0.4.7 I've got here), this
actually doesn't seem to be the case. Unless I'm totally mistaken,
multipathd actually does create DM maps as paths are discovered. And not
just fork/exec the utility as many sources (most notably the man page)
state.

No, I'm not asking for general advice on how old documentation relates
to new code. :)

My question here would be rather: Everywhere I've been looking at until
now there's seems to be a multipath %M:%m being run from udev. In
addition to the running daemon.

Is this redundant or does the run from udevd still add some major value?

Cheers,
Daniel 

Re: Multipath architecture.

[Hannes Reinecke]

Hi Daniel,

Daniel Stodden wrote:
> Hi.
> 
> Can someone spare a little time to help me understand the multipath
> utility and daemon a little better?
> 
> I read myself through the available documentation. The refbook says that
> it's multipath who's creating maps, and multipathd responsible for path
> checking.
> 
Well, yes, in principle.

> Running multipath (at least the version 0.4.7 I've got here), this
> actually doesn't seem to be the case. Unless I'm totally mistaken,
> multipathd actually does create DM maps as paths are discovered. And not
> just fork/exec the utility as many sources (most notably the man page)
> state.
> 
Indeed, that has changed. The multipath binary is basically obsolete
now, as the daemon is capable of discovering new paths itself.

> No, I'm not asking for general advice on how old documentation relates
> to new code. :)
> 
> My question here would be rather: Everywhere I've been looking at until
> now there's seems to be a multipath %M:%m being run from udev. In
> addition to the running daemon.
> 
Not everywhere :-)

What should be done is to have multipathd read uevent from a socket
provided by udev. Then multipathd won't race with udev and will handle
device events directly. The multipath binary itself is then just
used for maintenance and manual configuration changes.

Look on OpenSUSE 11.1 / SLES11 on how it's done.

> Is this redundant or does the run from udevd still add some major value?
> 
Definitely.
multipathd requires a device node for path checkers etc, so it has to wait
until udev has created one. Plus udev runs separate programs (vol_id etc)
which will add additional information to the uevent; some of which can
be used by multipathd.

The end goal here is to remove the scsi_id callout from multipathd and
use the udev provided information. And, indeed, have all information
provided by udev so that multipathd doesn't have to look for it
itself; most of which is already present, so it's only a slight change
to udev to add the remaining information.

Be advised that there are several bugs in the upstream code, so trying
this on a recent kernel with give you an 'interesting' user experience.
I have some (well, for rather large numbers of 'some') patches on my
git tree at

git://git.kernel.org/pub/scm/linux/kernel/git/hare/multipath-tools.git
branch sles11

so you might have a look there. And yes, I'll be posting them here
in the near future. I don't _want_ to keep them private, but somehow
customers insist on sending me new bug descriptions thus preventing
me from cleaning them up and posting them.

Do feel free to comment on them.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)