Re: [PATCH v5] scsi: Add hwmon support for SMART temperature sensors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/7/18 10:49 PM, Linus Walleij wrote:
S.M.A.R.T. temperature sensors have been supported for
years by userspace tools such as smarttools. This adds
support to read it from the kernel and adds a temperature
zone for the drive.

The temperature readout is however also a good fit for
Linux' hwmon subsystem. By adding a hwmon interface to dig
out SMART parameters, we can expose the drive temperature
as a standard hwmon sensor.

The idea came about when experimenting with NAS enclosures
that lack their own on-board sensors but instead piggy-back
the sensor found in the harddrive, if any, to decide on a
policy for driving the on-board fan.

The kernel thermal subsystem supports defining a thermal
policy for the enclosure using the device tree, see e.g.:
arch/arm/boot/dts/gemini-dlink-dns-313.dts
but this requires a proper hwmon sensor integrated with
the kernel.

With this driver, the hard disk temperatur can be read from
sysfs:

  > cd /sys/class/hwmon/hwmon0/
  > cat temp1_input
  38

If the harddrive supports one of the detected vendor
extensions for providing min/max temperatures we also
provide attributes for displaying that.

This means that they can also be handled by userspace
tools such as lm_sensors in a uniform way without need
for any special tools such as "hddtemp" (which seems
dormant).

This driver does not block any simultaneous use of
other SMART userspace tools, it's a both/and approach,
not either/or.

Reviewed-by: Guenter Roeck <linux@xxxxxxxxxxxx> # HWMON
Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
---
Hmm. I might be getting something wrong here, but the main problem with SMART values is that they are _not_ really standardized; plus any drive is free to implement whatever they want. Plus there are tons of SMART attribute values, and decoding just one seems to be a bit poor. At the same time having them in the kernel will just require us to implement lots of decoding, which I really would leave to userland.
So overall I'm not sure if that the right approach.

Cheers,

Hannes
--
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@xxxxxxx			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux