On Thu, Sep 26 2013 at 7:22pm -0400, Alasdair G Kergon <agk@xxxxxxxxxx> wrote: > On Thu, Sep 26, 2013 at 10:47:13AM -0700, Frank Mayhar wrote: > > 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. > > Then put more effort into debugging your daemon so it doesn't have > bugs that make it die? Implement the timeout in a robust independent > daemon if it's other code there that's unreliable? > > > 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. > > In what way are your requirements so different that a locked-into-memory > monitoring daemon cannot implement this timeout? Frank, I had a look at your patch. It leaves a lot to be desired, I was starting to clean it up but ultimately found myself agreeing with Alasdair's original point: that this policy should be implemented in the userspace daemon. Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
