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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
