On Thu, Jan 02 2020 at 5:45pm -0500, Gabriel Krisman Bertazi <krisman@xxxxxxxxxxxxx> wrote: > From: Anatol Pomazau <anatol@xxxxxxxxxx> > > 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@xxxxxxxxxx> > Signed-off-by: Frank Mayhar <fmayhar@xxxxxxxxxx> > Co-developed-by: Bharath Ravi <rbharath@xxxxxxxxxx> > Signed-off-by: Bharath Ravi <rbharath@xxxxxxxxxx> > Co-developed-by: Khazhismel Kumykov <khazhy@xxxxxxxxxx> > Signed-off-by: Khazhismel Kumykov <khazhy@xxxxxxxxxx> > Signed-off-by: Anatol Pomazau <anatol@xxxxxxxxxx> > Co-developed-by: Gabriel Krisman Bertazi <krisman@xxxxxxxxxxxxx> > Signed-off-by: Gabriel Krisman Bertazi <krisman@xxxxxxxxxxxxx> 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
