Re: [PATCH 13/14] ib_srp: Implement transport layer ping

[Bart Van Assche <bvanassche@xxxxxxx>]

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