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 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. 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. 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? -- Martin K. Petersen Oracle Linux Engineering
