Add Raw Format for Seagate Error Rates (ST4000DM004-2CV104)

[Kendy Kutzner]

The Seagate Barracuda ST4000DM004-2CV104 I own reports error rates in attributes 1, 7, and 159 in an unusual way: First, the number of errors (16bit), then the number of operations (32 bit).

The added patch adds a new RAWFMT, and enables it in the drivesdb for my disk.

[Kendy Kutzner]

Forgot to add: the scarce sources for my statement about the meaning of the bits are below. I've found nothing really authoritative and/or recent.

​http://www.users.on.net/~fzabkar/HDD/Seagate_SER_RRER_HEC.html (and links from here, in particular to comp.sys.ibm.pc.hardware.storage in 2009)

​https://www.truenas.com/community/threads/seagate-ironwolf-smart-test-raw_read_error_rate-seek_error_rate.68634/post-470741 (linking to the first source)

​https://forums.unraid.net/topic/31038-solved-seagate-with-huge-seek-error-rate-rma/?do=findComment&comment=296103 (linking to the first source)

​https://serverfault.com/a/495259

​https://yksi.ml/

[Christian Franke]

Thanks for this patch and the information about the Seagate attributes.

I prefer a more generic quotient syntax for error rates (errors/ops), sorry.

This could already be enabled with -v 1,raw24/raw32:543210 or even -v 1,raw24/raw32 if the reserved attribute byte is always zero.

We could possibly add raw16/raw32 for convenience. As any addition, it would require extra steps for database merges.

[Kendy Kutzner]

Thanks Christian for your quick reply.

I prefer a more generic quotient syntax for error rates (errors/ops), sorry.

I'd don't fully comprehend what you desire here. Can you please elaborate? I'm happy to modify my patch.

The reserved attributes on the drives I have here are indeed zero right now, so -v 1,raw24/raw32 does produce output that is seemingly correct (sample size: 2).

An addition of raw16/raw32 format might be more technically correct. I don't understand the database merge requirements.

Please advise on how to proceed.

PS: some background information. I'm using ​https://github.com/influxdata/telegraf/tree/master/plugins/inputs/smart to graph some disk attributes, which (for better or worse) parses the output of smartctl.

[Christian Franke]

A new output format would (IMO) not provide much benefit for the end user and would definitely break backward compatibility with drivedb.h branches.

This patch is backward compatible to all still maintained branches. If it works for you, I will apply it soon:

drivedb.h

@@ -4089 +4089 @@
       // ST4000DM004-2CV104/0001 (TRIM: no), ST4000DM005-2DP166/0001, ST8000DM004-2CX188/0001
     "ST(2000DM00[589]|3000DM007|4000DM00[45]|6000DM003|8000DM004)-.*",
     "", "",
+    "-v 1,raw24/raw32:543210 "
+    "-v 7,raw24/raw32:543210 "
+    "-v 188,raw16 "
+    "-v 195,raw24/raw32:543210 "
     "-v 200,raw48,Pressure_Limit "
-    "-v 188,raw16 -v 240,msec24hour32"
+    "-v 240,msec24hour32"
   },
   { "Seagate Desktop HDD.15", // tested with ST4000DM000-1CD168/CC43, ST5000DM000-1FK178/CC44,
       // ST6000DM001-1XY17Z/CC48

If possible, please also provide a smartctl -x -a ... output of an affected device.

PS: Telegraf developers might want to try smartctl --json (since 7.0) which could significantly ease parsing.

[Kendy Kutzner]

Your patch looks sensible to me. (With the obvious caveat that creating a raw24 out of two bytes is not fully right).

I do agree that telegraf parsing the textual output of smartctl is sub-optimal.

[Kendy Kutzner]

a seagate drive showing peculiar reporting in attributes 1, 7, and 195

[Kendy Kutzner]

I've just purchased a Seagate IronWolf ST4000VN008-2DR166, which shows the same behavior. Any chance to apply this patch?

[Christian Franke]

Any chance to apply this patch?

Yes, but it may take some time, see the FAQ.

For now, add it to a local drive database file. See -B section on smartctl man page for details.

[jay]

If the specification below is accurate, the error field of attributes id 1 and 195 is 24 bit, so the format of these attributes should be raw24/raw32 without byteorder.
​https://t1.daumcdn.net/brunch/service/user/axm/file/zRYOdwPu3OMoKYmBOby1fEEQEbU.pdf

According to the above specification, attribute id 188 is divided into three 16-bit fields, so please don't delete the -v 188,raw16 part.