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

[Bart Van Assche <bvanassche@xxxxxxx>]

On Wed, Dec 21, 2011 at 3:05 AM, David Dillow <dillowda@xxxxxxxx> wrote:
> We don't want to leave a target blocked indefinitely -- commands caught
> in the blocked queue won't be reissued until the queue is unblocked --
> but we may want to keep the sdX mappings around for a long time.
> fast_io_fail_tmo gives us the ability to do that -- the expiration of
> fast_io_fail_tmo unblocks the queue and allows commands to be failed due
> to the transport error. See commit f2818663.

Our opinions may differ here. My opinion is that for some use cases it
is crucial to be able to block a target indefinitely, e.g. when there
is only a single path between initiator and target and when the user
prefers that I/O blocks instead of encountering I/O errors. See e.g.
the "iSCSI settings for iSCSI root" section in the iSCSI README
(http://www.open-iscsi.org/docs/README).

Regarding commit f2818663: as far as I can see what that commit does
is to make it impossible for a user to set fast_io_fail_tmo == -1
together with dev_loss_tmo > SCSI_DEVICE_BLOCK_MAX_TIMEOUT. That
change is specific to the FC code - only the FC transport code limits
the blocked state time to the SCSI_DEVICE_BLOCK_MAX_TIMEOUT limit.

> Also, these settings can be used to help tune multipath failover for
> devices with relatively long LUN transfer times (say with RDAC) vs short
> ones (ALUA). You still don't want the mappings to go away, but you want
> to move data to the other paths in a reasonably quick fashion.
> http://lkml.org/lkml/2008/1/7/244 talks about this a bit.

In a multipath setup the ping_interval, ping_timeout, recovery_tmo and
max_reconnects parameters (all added via this patch series) should be
sufficient to allow control over how quickly multipath failover
happens.

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