Re: [RFC PATCH v2 0/3] add library to check if device is a valid path

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

 



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?

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.

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.

Regards
Martin

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



--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel





[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux