Guenter, > If and when drives are detected which report bad information, such > drives can be added to a blacklist without impact on the core SCSI or > ATA code. Until that happens, not loading the driver solves the > problem on any affected system. My only concern with that is that we'll have blacklisting several places. We already have ATA and SCSI blacklists. If we now add a third place, that's going to be a maintenance nightmare. More on that below. >> My concerns are wrt. identifying whether SMART data is available for >> USB/UAS. I am not too worried about ATA and "real" SCSI (ignoring RAID >> controllers that hide the real drives in various ways). OK, so I spent my weekend tinkering with 15+ years of accumulated USB devices. And my conclusion is that no, we can't in any sensible manner, support USB storage monitoring in the kernel. There is no heuristic that I can find that identifies that "this is a hard drive or an SSD and attempting one of the various SMART methods may be safe". As opposed to "this is a USB key that's likely to lock up if you try". And that's ignoring the drives with USB-ATA bridges that I managed to wedge in my attempt at sending down commands. Even smartmontools is failing to work on a huge part of my vintage collection. Thanks to a wide variety of bridges with random, custom interfaces. So my stance on all this is that I'm fine with your general approach for ATA. I will post a patch adding the required bits for SCSI. And if a device does not implement either of the two standard methods, people should use smartmontools. Wrt. name, since I've added SCSI support, satatemp is a bit of a misnomer. drivetemp, maybe? No particular preference. > The one USB/UAS connected SATA drive I have (a WD passport) reports > itself as "WD ", not as "ATA ". I would expect other drives > to do the same. Yes. Most vendors are too fond of their brand names to put "ATA" in there. So my suggestion is to relax the heuristic to trigger on the ATA Information VPD page only and ignore the name. Also, there are some devices that will lock up the way you access that VPD page. So a tweak is also required there. To avoid the multiple blacklists and heuristic collections my suggestion is that I introduce a helper function in SCSI (based on what I did in the disk driver) that can be called to identify whether something is an ATA device. And then the hwmon driver can call that and we can keep the heuristics in one place. If a device turns out to be problematic wrt. getting the ATA VPD for the purpose of SMART, for instance, it will also need to be blacklisted for other reasons in SCSI. So I would really like to keep the heuristics in one place. -- Martin K. Petersen Oracle Linux Engineering
