[dm-devel] dm mpath: Add timeout mechanism for queue_if_no_path

[Khazhismel Kumykov]

On Mon, Jan 6, 2020 at 11:28 AM Mike Snitzer <snitzer at redhat.com> wrote:
>
> On Thu, Jan 02 2020 at  5:45pm -0500,
> Gabriel Krisman Bertazi <krisman at collabora.com> wrote:
>
> > From: Anatol Pomazau <anatol at google.com>
> >
> > Add a configurable timeout mechanism to disable queue_if_no_path without
> > assistance from multipathd.  In reality, this reimplements the
> > no_path_retry mechanism from multipathd in kernel space, which is
> > interesting for cases where we cannot rely on a daemon being present all
> > the time, in case of failure or to reduce the guest footprint of cloud
> > services.
> >
> > Despite replicating the policy configuration on kernel space, it is
> > quite an important case to prevent IOs from hanging forever, waiting for
> > userspace to behave correctly.
> >
> > Co-developed-by: Frank Mayhar <fmayhar at google.com>
> > Signed-off-by: Frank Mayhar <fmayhar at google.com>
> > Co-developed-by: Bharath Ravi <rbharath at google.com>
> > Signed-off-by: Bharath Ravi <rbharath at google.com>
> > Co-developed-by: Khazhismel Kumykov <khazhy at google.com>
> > Signed-off-by: Khazhismel Kumykov <khazhy at google.com>
> > Signed-off-by: Anatol Pomazau <anatol at google.com>
> > Co-developed-by: Gabriel Krisman Bertazi <krisman at collabora.com>
> > Signed-off-by: Gabriel Krisman Bertazi <krisman at collabora.com>
>
> This seems like a slippery slope.
>
> I've heard this line of dm-multipath concern from Google before
> (e.g. doesn't want to rely on availability of userspace component).
>
> Thing is, to properly use dm-multipath (e.g. to reinstate failed paths)
> multipathd really is needed no?
Yeah, in order to reinstate the failed paths, or any full recovery, we
do need the user space component to be running, and this doesn't aim
to change the responsibilities here. Rather, we're aiming to avoid
in-kernel hangs/processes lingering indefinitely in unkillable sleep
due to buggy/unavailable/down userspace multipath daemon.
>
> If not, how is it that the proposed patch is all that is missing when
> multipathd isn't running?  I find that hard to appreciate.
>
> So I'm inclined to not accept this type of change.  But especially not
> until more comprehensive context is given for how Google is using
> dm-multipath without multipathd.

This patch isn't aimed at enabling dm-multipath without a userspace
multipath daemon, rather to avoid processes hanging indefinitely in
the event the daemon is unable to proceed (for whatever reason).

>
> Thanks,
> Mike
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4843 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20200106/0775e057/attachment.p7s>