On Mon, Dec 19, 2011 at 10:32 PM, David Dillow <dillowda@xxxxxxxx> wrote: > Part of the problem is introduced by allowing for permanent connections > rather than using the familiar dev_loss_tmo and fast_io_fail_tmo > parameters from other SCSI transports. For instance, in the FC > transport, rports are allowed to disappear for up to dev_loss_tmo > seconds before being removed from the SCSI device tree. Until they have > been gone for fast_fail_io_tmo seconds, they are blocked (as is error > handling to prevent offlining devices). Once they have been gone longer > that fast_fail_io_tmo, they become unblocked and new IO will be failed. I'm not convinced an equivalent of fast_fail_io_tmo is necessary for the SRP transport. If a target disappears briefly from the IB fabric what will happen with the posted patch series is that the initiator is blocked during one ping interval and also that a reconnect is triggered. Also, some SCSI commands may be reissued after reconnecting. But that shouldn't have any adverse consequences, isn't it ? 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
