Re: RFC for multipath queue_if_no_path timeout.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux