On 01/14/2012 05:56 AM, Bart Van Assche wrote: > Add the necessary functions in the SRP transport module to allow > an SRP initiator driver to implement transport layer recovery. > This includes: > - A ping mechanism to check whether the transport layer is still > operational. > - Support for implementing fast_io_fail_tmo, the time that should > elapse after having detected a transport layer problem and > before failing I/O. > - Support for implementing dev_loss_tmo, the time that should > elapse after having detected a transport layer problem and > before removing a remote port. > I was updating my iscsi dev loss patch when I saw this is still not merged. Not sure about the ping code, but I think the dev loss tmo and fast io fail related stuff should go to scsi_transport_template. We can then add some common code to start the timers/delayed_work_queues, stop them, set/get the value from sysfs, etc that all the transport classes can then call. For the srp code to use this patch, it was not clear to me what happens if dev_loss_tmo fires, but then the port comes back online. It looks like the target and its devices get deleted like with FC when the dev_loss_tmo fires. Is there something to automatically re-add the path/port/target when the issue is resolved? Was it on the patches that did not make the list (I only saw 6 patches out of 18 on linux-scsi) or do we have some userspace daemon that figures out when paths/ports/targets come back? Also I think the patch that has ib_srp call srp_start_tl_fail_timers and srp_block_rport did not make the list. For the ping code, does it use TUR because there is not a transport way to test the path/port/transport/interconnect? -- 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
