In multipath manual document, multipath -q command is described as:
"-q allow device tables with queue_if_no_path when multiathd is not running".
However the command does not take effect when we testing it.
About use-case, In my opinion, sometimes we need to stop multipath service temporarily (for example: multipath version upgrade), but we do not want IO interrupt during those times even path down existed, so we can execute “multiath -q” to keep IO queue until we starting service after version upgrade.
Cheers,
Tang
发件人: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
收件人: Hannes Reinecke <hare@xxxxxxx>,
抄送: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>, device-mapper development <dm-devel@xxxxxxxxxx>, tang.junhui@xxxxxxxxxx, zhang.kai16@xxxxxxxxxx
日期: 2016/10/12 10:53
主题: Re: [dm-devel] [PATCH] libmultipath: fix multipath -q command logic
发件人: dm-devel-bounces@xxxxxxxxxx
On Tue, Oct 11, 2016 at 12:33:43PM +0200, Hannes Reinecke wrote:
> 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: [dm-devel] [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.
I think you are dealing with a different issue. the "-q" option for
multipath just overrides the default behaviour of not enabling
queue_if_no_path when creating a multipath device is multipathd isn't
running. For this, we don't care if multipathd will start running in
the future, because if/when multipathd does start up, it will set the
queue_if_no_path flag itself. We only care about now, when we know it's
not running.
Really, I doubt that anyone ever uses the -q option. So your change in
how multipath checks if multipathd is running is fine by me. However,
you also changed what the "-q" option does. Previously, it just kept
multipath from disabling "queue_if_no_path" on devices that were
configured to have it, when multipathd wasn't running. With your code,
doesn't it now make all devices set queue_if_no_path if multipathd isn't
running, including devices that weren't configured to set it even when
multipathd is running? Is there a reason for this? In general, setting
"queue_if_no_path" when multiapthd isn't running is a bad idea, since
the paths will never come back, and nothing will ever disable the
queueing. That's why I said that I doubt anybody uses the option.
Forcing all devices to set "queue_if_no_path", even if they weren't
configured to, seems even less useful. Or is there actually a use-case
that I'm missing here?
-Ben
>
> 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
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
