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?
