Re: [PATCH] libmultipath: fix multipath -q command logic

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

 



On 10/11/2016 11:17 AM, tang.junhui@xxxxxxxxxx wrote:
Hello Hannes, Ben,
Could you have a review for this patch, any comment will be highly
appreciated.

Thanks,
Tang




发件人:         Christophe Varoqui <christophe.varoqui@xxxxxxxxxxx>
收件人:         tang.junhui@xxxxxxxxxx,
抄送:        Bart Van Assche <bart.vanassche@xxxxxxxxxxx>, device-mapper
development <dm-devel@xxxxxxxxxx>, zhang.kai16@xxxxxxxxxx
日期:         2016/10/11 14:59
主题:        Re:  [PATCH] libmultipath: fix multipath -q
command logic
发件人:        dm-devel-bounces@xxxxxxxxxx
------------------------------------------------------------------------



Hannes, Ben,

are you ok with the solution to these two issues.
Seems sane to me.

This actually is only part of the story.

The whole idea of issuing 'multipath' is to check if a given path _should_ be multipathed (as this is typically called from an udev event). But as it's called from an udev event we cannot rely on the multipath daemon to be started; we might just handle an event which came in before multipathd got started from systemd. So checking for the PID file is not enough, we need to check if the daemon will be started eventually. And in fact checking the PID file or calling mpath_connect() is equivalent, with the added advantage the mpath_connect() will start the daemon _if enabled by systemd_. So this patch doesn't help much, as it doesn't solve the main problem of figuring out if multipathd _should_ be started.

I've done a patch for checking the '.wants' directories from systemd, but this obviously will only work if the OS is systemd-based. And it's not really perfect, as there are corner-cases where just checking for the .wants directory is not enough.

Cheers,

Hannes
--
Dr. Hannes Reinecke		      zSeries & Storage
hare@xxxxxxx			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

--
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