On Sat, Dec 24, 2011 at 8:07 PM, David Dillow <dillowda@xxxxxxxx> 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. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html