On 12/16/19 6:35 PM, Martin K. Petersen wrote:
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.
Agreed, if we extend this to SCSI, satatemp is less than perfect.
drivetemp ? disktemp ? I am open to suggestions, with maybe a small
personal preference for disktemp out of those two.
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.
Fine with me. I wanted to be as restrictive as possible.
Also, there are some devices that will lock up the way you access that
VPD page. So a tweak is also required there.
Do you have details ? Do I need to add a call to scsi_device_supports_vpd(),
maybe ?
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.
Fine with me. My only concern is that I don't want the driver to disappear
into nowhere-land (again).
Thanks,
Guenter
