[lkml]   [2019]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/1] Summary: hwmon driver for temperature sensors on SATA drives
On 2019/12/17 12:57, Guenter Roeck wrote:
> On 12/16/19 6:35 PM, Martin K. Petersen wrote:
>> Guenter,
>>> If and when drives are detected which report bad information, such
>>> drives can be added to a blacklist without impact on the core SCSI or
>>> ATA code. Until that happens, not loading the driver solves the
>>> problem on any affected system.
>> My only concern with that is that we'll have blacklisting several
>> places. We already have ATA and SCSI blacklists. If we now add a third
>> place, that's going to be a maintenance nightmare.
>> More on that below.
>>>> 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).
>> OK, so I spent my weekend tinkering with 15+ years of accumulated USB
>> devices. And my conclusion is that no, we can't in any sensible manner,
>> support USB storage monitoring in the kernel. There is no heuristic that
>> I can find that identifies that "this is a hard drive or an SSD and
>> attempting one of the various SMART methods may be safe". As opposed to
>> "this is a USB key that's likely to lock up if you try". And that's
>> ignoring the drives with USB-ATA bridges that I managed to wedge in my
>> attempt at sending down commands.
>> Even smartmontools is failing to work on a huge part of my vintage
>> collection. Thanks to a wide variety of bridges with random, custom
>> interfaces.
>> So my stance on all this is that I'm fine with your general approach for
>> ATA. I will post a patch adding the required bits for SCSI. And if a
>> device does not implement either of the two standard methods, people
>> should use smartmontools.
>> Wrt. name, since I've added SCSI support, satatemp is a bit of a
>> misnomer. drivetemp, maybe? No particular preference.
> Agreed, if we extend this to SCSI, satatemp is less than perfect.
> drivetemp ? disktemp ? I am open to suggestions, with maybe a small
> personal preference for disktemp out of those two.

"disk" tend to imply HDD, excluding SSDs. So my vote goes to
"drivetemp", or even the more generic, "devtemp".

Damien Le Moal
Western Digital Research

 \ /
  Last update: 2019-12-17 06:51    [W:0.071 / U:4.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site