Linux In 2020 Can Finally Provide Sane Monitoring Of SATA Drive Temperatures

[phoronix]

Phoronix: Linux In 2020 Can Finally Provide Sane Monitoring Of SATA Drive Temperatures

Here is another long overdue kernel change... For more than a decade there have been patches trying to get SATA/SCSI drive temperature monitoring working nicely within the Linux kernel but none of that work ever made it through for mainlining. That has left various user-space tools to provide the functionality, but in doing so that has required root access and not to mention the need to first install said utilities. Well, with Linux 5.6 in 2020, there is finally a proper drive temperature driver for disks and solid-state drives with temperature sensors...

http://www.phoronix.com/scan.php?page=news_item&px=2020-Linux-Kernel-SATA-Temps

[numacross]

I hope this is well tested because there are some caveats even with using hddtemp on a HDD that's currently asleep or in low power mode. Depending on the drive type and manufacturer it can work fine, silently fail or in the worst case spin the drive up unnecessarily.

[dispat0r]

I hope this is well tested because there are some caveats even with using hddtemp on a HDD that's currently asleep or in low power mode. Depending on the drive type and manufacturer it can work fine, silently fail or in the worst case spin the drive up unnecessarily.

Lets hope that isn't the case. I use smartd(smartmon) which removes sleeping drives automatically.

[birdie]

For some reasons lm-sensors maintainers have refused to add the reporting of various additional metrics of Intel CPUs, like voltage and power consumption

It's the same for modern AMD CPUs which need a 3d-party driver.

I really cannot find any rationale for this decision. As a Ryzen 3000 user I resorted to using the turbostats utility to report power consumption figures but it's so incredibly tedious when I could just type lm-sensors or use a dozen of monitoring apps which support lm-sensors.

[stormcrow]

For some reasons lm-sensors maintainers have refused to add the reporting of various additional metrics of Intel CPUs, like voltage and power consumption

It's the same for modern AMD CPUs which need a 3d-party driver.

I really cannot find any rationale for this decision. As a Ryzen 3000 user I resorted to using the turbostats utility to report power consumption figures but it's so incredibly tedious when I could just type lm-sensors or use a dozen of monitoring apps which support lm-sensors.

My educated guess would be at least some of the maintainers don't want to add to the burden of support. Any particular device can have different reporting interfaces, different gotchas, and different forms of brokenness, between different generations of hardware, firmware, model type, vendors, etc. The same is true of just about any hardware really. Ideally they'd have to test changes on all of those hardware types to be sure they work.

[birdie]

My educated guess would be at least some of the maintainers don't want to add to the burden of support. Any particular device can have different reporting interfaces, different gotchas, and different forms of brokenness, between different generations of hardware, firmware, model type, vendors, etc. The same is true of just about any hardware really. Ideally they'd have to test changes on all of those hardware types to be sure they work.

This couldn't be further from the truth. lm-sensors support various motherboards monitoring chips which are finicky as hell, vary from vendor to vendor (some of their inputs maybe connected/disconnected), have varying ratios for their outputs and other infinite quirks.

At the same time CPUs are fairly standard and once you support a CPU family, you're guaranteed it will work forever for all users. The amount of work to support HW monitoring chips vs CPUs is two orders of magnitude more.

[Azrael5]

Just 30 years. A big improvement since then.

[tuxd3v]

I hope this is well tested because there are some caveats even with using hddtemp on a HDD that's currently asleep or in low power mode. Depending on the drive type and manufacturer it can work fine, silently fail or in the worst case spin the drive up unnecessarily.

Your reply, is in the same way of thinking as mine would be..
Reading temps without waking up disks( as far as I know), is only possible via SCSI..
I was delaying implementing it in a tool, and now maybe I would need to continue that work because... I don't want the Load/Unload cycles to start killing the discs, and not only that... the power consumption of each disk goes to the roof each time it is waken up..

[Ropid]

For some reasons lm-sensors maintainers have refused to add the reporting of various additional metrics of Intel CPUs, like voltage and power consumption

It's the same for modern AMD CPUs which need a 3d-party driver.

I really cannot find any rationale for this decision. As a Ryzen 3000 user I resorted to using the turbostats utility to report power consumption figures but it's so incredibly tedious when I could just type lm-sensors or use a dozen of monitoring apps which support lm-sensors.

I read through the posts in that bug report discussion thread you linked to, and it's explained there. I understand what happened like this:

First, the code was actually implemented, just like people asked for. After the code was there, no one wanted to test it besides one single person. Because people didn't want to test and ignored it, the code then never had a chance to get ready for inclusion into the kernel. Over time other parts of the kernel changed and the experimental code was not good anymore. The developer then gave up trying to get it ready.

[birdie]

I read through the posts in that bug report discussion thread you linked to, and it's explained there. I understand what happened like this:

First, the code was actually implemented, just like people asked for. After the code was there, no one wanted to test it besides one single person. Because people didn't want to test and ignored it, the code then never had a chance to get ready for inclusion into the kernel. Over time other parts of the kernel changed and the experimental code was not good anymore. The developer then gave up trying to get it ready.

You can find hundreds of people to test sensors for a CPU family. For motherboards, it's usually quite a difficult task since there are literally thousands of different models and Linux is barely used by anyone. Meanwhile lm-sensors devs gladly develop drivers for motherboards yet they couldn't find testers for a CPU driver? Are you BS'ing me? I tested the driver right away and reported it was fine. Guenter Roeck also tested it - we already had two testers.

No, the reason was different: "Won't fix; the functionality overlaps with other functionality introduced into the kernel in the meantime, and I was unable to get review or test feedback other than my own on the outstanding patch".

No actual testing was required. He couldn't find the people to review the code. That was it. And then there was a lame excuse in terms of "overlapping". And now we have no lm-sensors drivers for advanced CPU reporting at all. FML.