* James Smart > Please don't shoot the messenger. I was trying to summarize the > evolution of FC into the kernel, highlight that the DM team knew of > the issue, had higher-priority issues, and that it applies to more > than FC. Having experienced first-hand this method of getting work > done, I certainly don't promote it as a productive way of doing > things. Sorry, didn't mean to shoot you! ;-) I mean "you" in the plural sense; «you SCSI people» - got the impression there is some kind of disdain towards the DM team (which would indeed be a counter-productive way of getting things done). Not my intention to offend anyone, and if I did anyway I apologise. It's just frusterating when things don't work... > I'm highlighting that - ok today, we get FC working, but then the > user puts DM on something else, like iSCSI or SAS/whatever, then it > too breaks - and that's ok ? Of course the best would be if it worked perfectly with all transports, and leaving things broken is of course not OK. In my strictly pragmatic opinion, though, having a functional DM+FC combo and and half-functional DM+<anything else> combos is better than having _only_ half-functional combos. > Using this analogy, to resolve the reuse-after-free issues, we simply > would have used the dont-tear-down patches to avoid teardown bugs, > like what the distros did. This too is a bad approach. Things need > to get fixed where things need to get fixed. We can add the FC > patch, but DM still needs to get fixed. Best would to have DM-multipath handle the disconnects gracefully, of course. But since it doesn't appear to be happening anytime soon: A workaround provided by the transport layer would be very welcome! I don't use iSCSI or SAS with DM so I don't know if such a workaround is wanted there too, but with FC it is necessary. Even if it is a bad approach it is much better than nothing, the way I see it. Regards -- Tore Anderson - 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
