Re: Disabling dev_loss_tmo?

[Tore Anderson <tore@linpro.no>]

* 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html