ah.... OK. At first glance, I didn't like simple addition of another flag. Although simple, it grows data structures quickly. It seems more representative of a state flag, or a iftest based on the state checking (e.g. we know we're blocked and whether we have failfast pending). But this is largely stylistic. Preferences ? I can post an alternative. -- james Mike Christie wrote:
James Smart wrote:Background: The states, in the transport are: event state -------------------------------- n/a running lose connectivity blocked fastfail timeout still blocked, but with fastfail indicatorMy patch changed this one. When this times out, I unblock the queue.dev_loss timeout unblocked/removed Question: The chkready helper in the transport catches race conditions where the block is being put in place, but queuecommand is running on another cpu, thus returning DID_IMM_RETRY. Your patch is updating chkready to look for the case when fastfail has fired, and returning DID_TRANSPORT_FASTFAIL ? Why ? The request queue would be blocked so there should be no call to queuecommand that would fall into this category - unless you are assuming that fastfail timeout is so fast that it could fall into the same race condition as blocked.In the patch, when the fast IO fail timer fires, I unblock the queues. + rport->fast_io_fail_timeout = 1; i->f->terminate_rport_io(rport); + scsi_target_unblock(&rport->dev); At that time IO would be queued on drivers and would hit that test and be failed. New IO would also be failed upwards by that check.
- 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
