On Mon, 2011-12-26 at 19:39 +0000, Bart Van Assche wrote: > On Sat, Dec 24, 2011 at 8:07 PM, David Dillow <[email protected]> wrote: > > This says to me that SRP should use the dev_loss_tmo semantics, though > > the naming of fast_io_fail vs replacement_timeout is a bit more of a > > question than I thought. I tend to think of SRP more in terms of FC than > > iSCSI, so I still prefer the former, but perhaps not as strongly now. > > Do we need dev_loss_tmo functionality ? Since multipathd switches over > if the active path is in the blocked state, the posted patch set > already provides a way to make multipathd switch over if communication > is lost.
I think so. multipathd isn't the only use case, though I think we need to reorganize the SRP device model to fully take advantage of dev_loss_tmo -- but that can come later. I'd like to see dev_loss_tmo take the place of max_reconnects to give admins an easy way to set a maximum time. -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
