Hi Guenter, > The most recent attempt was [1] by Linus Walleij. It went through a total > of seven iterations. At the end, it was rejected for a number of reasons; > see the provided link for details. This implementation resides in the > SCSI core. It originally resided in libata but was moved to SCSI per > maintainer request, where it was ultimately rejected. While I am sure I come across as a curmudgeon, regressions is a major concern for me. That, and making sure we pick the right architecture. I thought we were making good progress in that department when Linus abandoned the effort. > The feedback on this approach suggests to use the SCSI Temperature log > page [0x0d] as means to access drive temperature information. It is > unknown if this is implemented in any real SCSI drive. Almost every SCSI drive has it. > The feedback also suggests to obtain temperature from ATA drives, > convert it into the SCSI temperature log page in libata-scsi, and to > use that information in a hardware monitoring driver. The format and > method to do this is documented in [3]. This is not currently > implemented in the Linux kernel. Correct, but I have no qualms over exporting the SCSI temperature log page. The devices that export that page are generally well-behaved. 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). I am not sure why the SCSI temperature log page parsing would be complex. I will have to go check smartmontools to see what that is all about. The spec is as simple as can be. Anyway. I think the overall approach wrt. SCT and falling back to well-known SMART fields is reasonably sane and fine for libata. But I don't understand the pushback wrt. using the SCSI temperature log page as a conduit. I think it would be fine if this worked out of the box for both SCSI and ATA drives. The elephant in the room remains USB. And coming up with a way we can reliably detect whether it is safe to start poking at the device to discover if SMART is provided. If we eventually want to pursue USB, I think your heuristic stuff needs to be a library that can be leveraged by both libata and USB. But that doesn't have to be part of the initial effort. And finally, my concerns wrt. reacting to bad sensors remain. Not too familiar with hwmon, but I would still like any actions based on reported temperatures to be under user control and not the kernel. -- Martin K. Petersen Oracle Linux Engineering
