On Wed, Dec 21, 2011 at 3:05 AM, David Dillow <[email protected]> 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-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
