[dm-devel] dm mpath: Add timeout mechanism for queue_if_no_path
Mike Snitzer
snitzer at redhat.com
Mon Jan 6 16:28:33 UTC 2020
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?
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.
Thanks,
Mike
More information about the dm-devel
mailing list