On Sun, 2012-03-04 at 17:05 +0000, Bart Van Assche wrote: > On 02/26/12 06:39, David Dillow wrote: > > As I've previously said, this is better handled by user space and > > you add additional failure cases when you try to retrofit a transport > > ping into SRP. > > Let's look at this from another point of view. If it's possible for the > SRP protocol to implement most of the transport layer checking and error > handling in user space then that's possible for iSCSI and FC too. Are > you claiming that the device mapper layer and the multipath software > should be redesigned such that certain parts of the transport checking > and recovery mechanisms are moved from kernel space to user space, > including a backwards-incompatible change of the kernel ABI (sysfs) the > multipath software uses today ?
You mean, let's do it the way it already works? multipath implements path-checking on a *per-LUN* basis from user space. Today. No redesign needed. It already works on all SCSI transports. iSCSI has a protocol-defined mechanism to tell us when all LUNs on a given target are unavailable without waiting for the connection to be broken on a command timeout. I don't think FC has that, but it does have notification that a target is out of the fabric -- and all LUNs are unavailable. Both of these situations are communicated via an existing sysfs ABI, and the user space multipath code knows how to fail over and avoid checking those paths that are known to be bad. SRP does not have a protocol-defined way to check the link to the target. IB can tell us when a target leaves the fabric, like FC, but that's not what you're trying to implement -- you are attempting to fake the ping capability of iSCSI. Implementing "most" of the transport layer checking gives you a partial kernel implementation of the pinging already performed by user space, and adds bugs to it in that a single LUN experiencing issues may fail the whole path when the rest of the target is perfectly fine. Adding bugs while re-implementing user space prevents me from signing off on it. -- 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-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
