[dm-devel] [RFC PATCH v2 0/3] add library to check if device is a valid path

[Benjamin Marzinski]

On Fri, Sep 25, 2020 at 10:01:01AM +0000, Martin Wilck wrote:
> On Thu, 2020-09-24 at 20:08 -0500, Benjamin Marzinski wrote:
> > On Thu, Sep 24, 2020 at 07:22:21PM +0000, Martin Wilck wrote:
> > > 
> > > So, SID will call into libmultipath via libmpathvalid, udev will
> > > obtain
> > > the properties from SID, and multipathd will fetch them from udev
> > > in
> > > turn? Or will multipathd talk directly to SID? I seem to be missing
> > > the
> > > overall picture.
> > 
> > Yeah. SID will populate the udev database with the necessary udev
> > properties, and multipathd will get those udev properties just like
> > it
> > always does. 
> 
> But then I'm not getting how you'll get along with a SID-specific
> configuration for libmultipath's behavior. You want get_uid() to use
> direct sysfs access for SID, and use udev for multipath(d). How else
> would you achieve that?

In the future, libmapathvalid will have access to the udev properties
that SID will be passing back to udev, so it can use the same data.
Those values just aren't there yet. I admit, how exactly this will work
is not completely nailed down.
 
> More generally, I'm not quite convinced of the the design yet. The
> information flow kernel -> (sysfs or ioctl) -> libmultipath(sid mode) 
> -> libmpathvalid -> SID -> udev -> udev db -> libudev -> libmultipath
> (udev mode) -> multipathd is more complex than it needs to be. It might
> actually increase the lags experienced by multipathd, which will still
> have to wait for uevent workers to finish until it can be certain about
> device properties. Not to mention that SID must be rock stable and
> always available during boot, initrd processing, etc.

Yes, clearly SID will need to be just as robust as udev.

> Why don't we rather write a common library for determining WWIDs and
> the "should be multipathed" predicate, to be used by udev (with a
> plugin), multipath-tools, SID, and possibly other tools like systemd
> and LVM, with common, simple configuration, guaranteed to always
> provide the same results? I mean, libmultipath already has all the
> "intelligence" built-in to do this. We'd "just" need to cut down
> configuration options drastically to get more reprocucible results, and
> refactor things to obtain a minimalistic API. Unlike the current
> libmpathvalid design, this wouldn't be built on top of current
> libmultipath, rather vice-versa. multipath-tools would also benefit a
> lot from such work.

Right now a lot of this infomation is being gathered by libraries. For
udev's builtin commands, those libraries are already being called
directly. SID will just be calling all those libraries directly, instead
of having to exec a program that bascially just calles the library.
Obviously not everything is in a library, however. But the idea of WWID
library sounds great. libmultipath probably doesn't have all the
intelligence built-in, because I assume people would want this library
would handle more device types than multipath does. Although you are
correct that just with what libmultipath does now, it would still have
a use.

-Ben

> Regards
> Martin
> 
> -- 
> Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
> SUSE  Software Solutions Germany GmbH
> HRB 36809, AG Nürnberg GF: Felix
> Imendörffer
>