Re: Disabling dev_loss_tmo?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tore Anderson wrote:
So basically you're forcing breakage on users to corece the DM folks to
fix their end?  Maybe it's time to re-think that strategy, seeing that
it hasn't been fixed in such a long time it seems unlikely that they
would start bothering now.  SuSE and RH works around it anyway, so
everyone who's obedient enough to run the enterprise distros their
storage vendor tells them to won't have any problems.  Many of the DM
folks are employed by SuSE, RH, and various storage vendors - go figure.

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.

I'm just a simple user.  To me the most important ting is that it - and
by «it» I'm referring to the whole bundle of DM, SCSI, HBA driver, and
the rest of the system - actually works.

With no way of disabling dev_loss_tmo, it doesn't.  It will break after
intermittent failures, exactly the time where you need it to work the
most.  Knowing that the SCSI FC transport does the Right Thing isn't
really any consolation.

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 ?

The patch seems like a rather simple fix.  Quick and dirty, sure, but it
would actually help out the likes of me who are putting this stuff in
production.  And if it defaulted to remove_on_dev_loss=0, it wouldn't
really be intrusive either.  It seems that it will take a while to get
this properly fixed (both in DM and the -EEXIST issue), so what I'm
asking is just a way to make it work in the interim.

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.

I'll defer to James on what he'd like to see happen in his subsystem,
as this does set precendence.

-- james s

-
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux