Messages in this thread |  | | Subject | Re: [PATCH 1/1] hwmon: Driver for temperature sensors on SATA drives | From | Guenter Roeck <> | Date | Thu, 12 Dec 2019 20:18:11 -0800 |
| |
On 12/12/19 3:21 PM, Martin K. Petersen wrote: > > Linus, > >> It's a nice addition with the SCT command, I never figured that part >> out. Also nice how you register the scsi class interface I never saw >> that before, it makes it a very neat plug-in. > > Yep, I agree that the patch looks pretty good in general. There are just > a few wrinkles in the detection heuristics I would like to tweak. More > on that later. > > Yesterday I added support for the SCSI temperature log page and am > working through some kinks wrt. making this work for USB as well. > >> When I read the comments from the previous thread I got the impression >> the SCSI people wanted me to use something like the SCT transport and >> the hook in the SMART thing in the libata back-end specifically for >> [S]ATA in response to the SCT read log command. > > Our recommendation was for libata-scsi.c to export the SCSI temperature > log page, just like we do for all the other ATA parameters. > > However, in tinkering with this the last couple of days, I find myself > torn on the subject. For two reasons. First of all, there is no 1:1 > sensor mapping unless you implement the slightly more complex > environmental log page. Which isn't a big deal, except out of the > hundred or so SCSI devices I have here there isn't a single one that > supports it it. So in practice this interface would probably only exist > for the purpose of the libata SATL. > > The other reason the libata approach is slightly less attractive is that > we need all the same SMART parsing for USB as well. So while it is > cleaner to hide everything ATA in libata, the reality of USB-ATA bridges > gets in the way. That is why I previously suggested having a libsmart or > similar with those common bits. > > Anyway, based on what I've worked on today, I'm not sure that libata is > necessarily the way to go. Sorry about giving bad advice! We've > successfully implemented translations for everything else in libata over > the years without too much trouble. And it's not really that the > translation is bad. It's more the need to support it for USB as well > that makes things clunky. > >> I don't understand if that means the SCT read log also works >> on some SCSI drives, or if it is just a slot-in thing for >> ATA translation that has no meaning on SCSI drives. > > It's an ATA command. > > One concern I have is wrt. to sensor naming. Maybe my /usr/bin/sensors > command is too old. But it's pretty hopeless to get sensor readings for
You'll need the command (and libsensors) from the lm-sensors package version 3.5 or later for it to recognize SCSI/ATA drives.
> 100 drives without being able to tell which sensor is for which > device. Haven't looked into that yet. The links exist in > /sys/class/hwmon that would allow vendor/model/serial to be queried. >
There is a device/ subdirectory which points to that information. Is that what you are looking for ? "sensors" displays something like satatemp-scsi-5-0, which matches sd 5:0:0:0:
> Oh, and another issue. While technically legal according to the spec, I > am not sure it's a good idea to export a sensor per scsi_device. I have > moved things to scsi_target instead to avoid having bazillions of > sensors show up. Multi-actuator drives are already shipping. >
Not sure I understand what you mean with 'bazillions of sensors' and 'sensor per scsi_device'. Can you elaborate ? I see one sensor per drive, which is what I would expect.
Thanks, Guenter
> If I recall correctly, though, I seem to recall that you had some sort > of multi-LUN external disk box that warranted you working on this in the > first place. Is that correct? Can you refresh my memory? >
|  |