[dm-devel] RFC for multipath queue_if_no_path timeout.

Frank Mayhar fmayhar at google.com
Thu Sep 26 17:47:13 UTC 2013


On Thu, 2013-09-26 at 18:38 +0100, Alasdair G Kergon wrote:
> On Thu, Sep 26, 2013 at 10:31:56AM -0700, Frank Mayhar wrote:
> > Uh, huh.  And what about when (not if) _that_ fails?  (For one thing,
> > what if the stuckness caused by the queued I/O prevents the binary from
> > being successfully pulled in from storage?)
>  
> Lock the daemon in memory (or launch from ramdisk), don't allocate any new
> memory while it's doing critical monitoring, tell the OOM killer not to kill
> it, set high/real-time priority etc.
> 
> lvm2 and multipath-tools use some of these techniques and seem to cope OK.

Launching it from ramdisk won't help, particularly, since it still goes
through the block layer.  The other stuff won't help if a (potentially
unrelated) bug in the daemon happens to be being tickled at the same
time, or if some dependency happens to be broken and _that's_ what's
preventing the daemon from making progress.

And as far as lvm2 and multipath-tools, yeah, they cope okay in the kind
of environments most people have, but that's not the kind of environment
(or scale) we have to deal with.
-- 
Frank Mayhar
310-460-4042




More information about the dm-devel mailing list