On Mon, Jan 6, 2020 at 11:28 AM Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > 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? 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 >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
