Re: Corsair Force 3 SSD, no temperature sensor

Thanks the the response!

I can change the script, but currently it looks for the 
"Temperature_Celsius" line, and reads the value from it, no matter what 
drive it is, so I would have to put in some extra logic for it to 
specifically weed out these particular drives.  The servers have a good 
deal of spinning drives along with SSD's, and the temperature is 
averaged.   I'm kind of leery about chopping off values at that number, 
since I think technically 128 C is possible for a spinning disk.  It'd 
have to be probably a power short or fire or something, but still within 
possibility.

(Funny side note, since some SSD's made recently started reporting using 
a different numbering scheme, some of the nodes using smartctl 5.38 were 
reporting temperatures in the quadrillion degrees.  Those, I would be 
happy to ignore with an upper limit.)

Thanks for informing me about the drivedb.h not getting overwritten, 
that may be the solution I'm looking for, since I can push that out to 
all the boxes with my own custom config in it.

If you like, I'll try to gather all the info I can on this particular 
drive so that you can put it into the master drivedb.h. We can take that 
conversation offline, so that we don't clutter up the mailing list.

I appreciate the info, and thanks for making a great tool that helps me 
a lot!
On 3/7/2015 1:21 PM, Christian Franke wrote:
> Jonathan Russell wrote:
>> Hi,
>> I have a fairly large fleet of linux servers (500+) with a few custom
>> scripts on them to collect smart data and send it to a back-end 
>> database.
>> Some of the servers have SSD's that identify as:
>>
>> Model Family:     SandForce Driven SSDs
>> Device Model:     Corsair Force 3 SSD
>>
>> According to the manufacturer, these drives do not have temperature
>> sensors at all.
>> Attribute 194 is present in the smart output, (despite being commented
>> out normally in the drivedb.h file for this particular drive)
>> 194 Temperature_Celsius     0x0022   128   129   000    Old_age
>> Always       -       128 (0 127 0 129 0)
>
> Older sandforce drives return 0 if no sensor is available.
>
>> The attribute is always reporting 128, which is causing alerting
>> triggers for drive temperature to my administrators.
>
> Could you possibly change the 'alerting' script such that raw values 
> above some threshold are interpreted as 'unknown temperature' ?
>
>
>> I can manually edit the drivedb.h and simply change the value to:
>> 194 Ignore_this             0x0022   128   129   000    Old_age
>> Always       -       128 (0 127 0 129 0)
>> However, this means I can no longer update the drive db, as my changes
>> would be destroyed.  Is there a way to cause smartctl to ignore a value,
>> or rename it in this case?
>
> Add a custom drivedb entry to local drive database. This file is never 
> overwritten on drivedb.h update and should also not be overwritten on 
> smartmontools package update.
>
> See -B option on smartctl man page for the distribution specific 
> default path (usually /etc/smart_drivedb.h).
>
>
>> Since these disks do not have temperature sensors, is there a way that
>> the master drivedb.h can have a specific entry to ignore this value for
>> this drive?
>
> Hmm... we could possibly split the SandForce entry (with, without 
> sensor). Unfortunately for most drives I don't have the info whether a 
> sensor is present or not (or is optional). Added to my TODO list.
>
> Thanks,
> Christian
>


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/