[dm-devel] Disconcerting observation with multipathd's dmevent polling code

[Martin Wilck]

On Wed, 2018-11-28 at 10:57 -0600, Benjamin Marzinski wrote:
> On Wed, Nov 28, 2018 at 10:31:02AM +0100, Martin Wilck wrote:
> > 
> > If "remove" uevents is most important, what if we created an
> > additional
> > monitor for "kernel" uevents in multipathd? Those should be just as
> > reliable as dmevents, and for removal, we don't need the udev rule
> > processing. Having ACTION==remove and the KERNEL name should be
> > sufficient. This would obviously not work for "change" or "add"
> > events.
> 
> That would certainly help, but again, I would contend that it's not
> as
> reliable as devmapper. From the netlink man page
> 
> "However, reliable transmissions from kernel to user are impossible
> in
> any case. The kernel can't send a netlink message if the socket
> buffer
> is full: the message will be dropped and the kernel and the user-
> space
> process will no longer have the same view of kernel state. It is up
> to
> the application to detect when this happens (via the ENOBUFS error
> returned by recvmsg(2)) and resynchronize."
> 
> In this case, we would need to rescan everything on ENOBUFS, but at
> least we would get a notification.

By running the uevent listener with RT priority and using a suitably
large receive buffer, we should be able to reduce the likelihood of
this happening such that it doesn't really matter anymore. In real OOM
situations, multipathd is pretty much hosed anyway. multipathd hasn't
been written with resilience against memory pressure in mind.

But for the time being, I'm fine with your dm_is_mpath patch.

Thanks
Martin