drive database entry: Seagate Enterprise Capacity 3.5 HDD 1TB ST1000NM0008-2F2100

[Nathan Stratton Treadway]

We have just installed a new Seagate Enterprise Capacity 3.5 HDD drive, size 1TB, which reports a Device Model of ST1000NM0008-2F2100.

The drivedb.h file currently has an entry for "Seagate Enterprise Capacity 3.5 HDD", but the regex for that entry does not include "8" just before the hyphen, so I don't believe so I don't believe it would apply to this drive. (The system where this drive is installed is running a very old version of smartctl so I can't directly try out a recent version of the drivedb.h file.)

Also, I noticed that the current entry includes -v options for attribute 188 and 240, but the ST1000NM0008 drive also appears to need one for attribute 9 (for which the raw value shown in the log file was "276132037394433").

[Nathan Stratton Treadway]

smartctl -x output

[Nathan Stratton Treadway]

For what it's worth, the Seagate data sheet for this drive is available at

​https://www.seagate.com/www-content/datasheets/pdfs/ent-cap-3-5-hdd-v5-1-data-sheetDS1917-1-1611US-en_US.pdf

[Christian Franke]

Also, I noticed that the current entry includes -v options for attribute 188 and 240, but the ST1000NM0008 drive also appears to need one for attribute 9 (for which the raw value shown in the log file was "276132037394433").

276132037394433 -> 0x??fb2400000001 -> 1 hour + unknown milliseconds.

If possible, please test whether smartctl -v 9,msec24hour32 ... prints a reasonable power on time.

smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)

Please note that I dropped the maintenance of the 5.40 drivedb.h branch​ with r4692. But you could add local entries via /etc/smart_drivedb.h which is automatically loaded first if present.

[Nathan Stratton Treadway]

I'm running the smartmontools package that comes installed on a Debian Squeeze system, and though the smartctl banner says "5.40", I found that the smartmontools package actually gives its version number as "5.39.1+svn3124-2" -- and it turns out the 5.40 version of the smart_drivedb.h file is unusable because FORMAT arguments such as raw24/raw32 and msec24hour32 are not recognized....

I though I would try using "-r ataioctl" on the Squeeze system and then piping that to a system running smartctl 6.5 in order to test "msec24hour32"... but in my initial trials the 6.5 instance aborted with errors along the lines of "Smartctl open device: - failed: <stdin>(11): Syntax error: No information found". I will look more closely to see if I can figure out a way to get this to work... but meanwhile was curious if you thought this was likely to be possible (or if, e.g., the format of the ataioctl output is incompatible between the two versions)?

[Nathan Stratton Treadway]

(... never mind, I got it working. The trick seems to have been to use the same READ AND DISPLAY DATA options on both systems, and to use a few individual options rather than "-x". I still get some "REPLAY-IOCTL: Warning: Command #4 is out of sync"-type messages at times, but they don't seem to affect the testing for the drivedb.h file.)

[Nathan Stratton Treadway]

Yes, when displaying the attributes using v6.5, attribute 9's values look correct with "-v 9,msec24hour32" -- in particular, if I run the command twice X seconds apart, the value printed for attribute 9 also advances by X seconds.

# date; smartctl -iA -r ataioctl,2  /dev/sda  | ssh HOST "smartctl -iA - | grep Hours"
Sun Sep  9 18:43:21 EDT 2018
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -      90h+41m+30.770s
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -      88h+57m+40.926s
# date; smartctl -iA -r ataioctl,2  /dev/sda  | ssh HOST "smartctl -iA - | grep Hours"
Sun Sep  9 18:43:48 EDT 2018
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -      90h+41m+57.947s
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -      88h+58m+08.103s

I got the above results by adding the following stanza to /etc/smart_drivedb.h on the v6.5 system:

  { "Seagate Enterprise Capacity 3.5 HDD 1TB",
    "ST1000NM0008-.*",
    "", "",
    "-v 9,msec24hour32 -v 188,raw16 -v 240,msec24hour32"
  },

[Christian Franke]

r4766, r4767.

[Nathan Stratton Treadway]

I noticed that the new entry for ST[12]000NM0008 and the old entry both have a modelfamily value of "Seagate Enterprise Capacity 3.5 HDD". Eyeballing the drivedb.h file it appears that generally the modelfamily string is only reused in cases where the entries are differentiated by firmware versions.

I don't have a specific suggestion of a family name to use instead, but was wondering if it might potentially cause user confusion to have the same family name used for two different entries with different option-preset-lists specified?

(Perhaps just "Seagate Enterprise Capacity 3.5 HDD [2]" or some other simple way to differentiate the entries?)

[Christian Franke]

From the smartmontools point of view, it is same series (same "marketing name") with different firmware due to differing attribute 9.

[Christian Franke]

Milestone renamed