On Fri, 2011-12-23 at 16:56 -0600, Mike Christie wrote: > On 12/23/2011 04:34 PM, David Dillow wrote: > > We should match the rest of the SCSI stack unless there is good reason > > to go our own way. The iSCSI transport can do what it does because it > > has a native ping, but I'm not convinced they should have introduced new > > semantics and/or names when taking advantage of that. As far as I can > > tell without deeply studying it, replacement_timeout is equivalent to > > fast_io_fail_tmo. > > > > iSCSI replacement_timeout is the same as fast_io_fail_tmo for FC. iSCSI > replacement_timeout actually came first so you should say FC should have > copied our name :) Indeed, some git-foo seems to indicate both stacks had that functionality mainlined in 2.6.18, with iSCSI getting it first. FC should have used your name. > iSCSI had replacement_timeout first, and it only fails IO, because at > the time things did not handle hotplug removal well, and I did not know > there was a need for the removal. There is patch to add dev_loss_tmo to > the iSCSI layer. There have been some bugs though, so I have not pushed > it. But it will also work like FC where you cannot turn it off. > > SAS has something like the dev_loss_tmo. It does not have something like > the fast_io_fail/replacement_timeout. This says to me that SRP should use the dev_loss_tmo semantics, though the naming of fast_io_fail vs replacement_timeout is a bit more of a question than I thought. I tend to think of SRP more in terms of FC than iSCSI, so I still prefer the former, but perhaps not as strongly now. I still believe consistency is good -- what do the SCSI devs think here? Should we work on getting a consistent name for this property -- and if so, which one -- or does the name not matter? -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office -- 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
