Custom Query (1386 matches)

After reading the full datasheet (pdf available on request) I've come up with the following changes:

# diff -u /usr/local/share/smartmontools/drivedb.h /usr/local/share/smartmontools/drivedb.h.new
--- /usr/local/share/smartmontools/drivedb.h    2017-11-14 02:36:32.359088000 +0000
+++ /usr/local/share/smartmontools/drivedb.h.new        2017-11-14 02:33:58.020915000 +0000
@@ -736,7 +736,7 @@
     "-v 241,raw48,Host_Writes"
   },
   { "InnoDisk InnoLite SATADOM D150QV-L SSDs", // tested with InnoLite SATADOM D150QV-L/120319
-    "InnoLite SATADOM D150QV-L",
+    "InnoLite SATADOM D150QV",
     "", "",
   //"-v 1,raw48,Raw_Read_Error_Rate "
   //"-v 2,raw48,Throughput_Performance "
@@ -744,18 +744,18 @@
   //"-v 5,raw16(raw16),Reallocated_Sector_Ct "
   //"-v 7,raw48,Seek_Error_Rate " // from InnoDisk iSMART Linux tool, useless for SSD
   //"-v 8,raw48,Seek_Time_Performance "
-  //"-v 9,raw24(raw8),Power_On_Hours "
+  //"-v 9,raw48,Power_On_Hours "
   //"-v 10,raw48,Spin_Retry_Count "
   //"-v 12,raw48,Power_Cycle_Count "
     "-v 168,raw48,SATA_PHY_Error_Count "
-    "-v 170,raw48,Bad_Block_Count "
-    "-v 173,raw48,Erase_Count "
+    "-v 170,raw16,Bad_Block_Count_New/Tot "
+    "-v 173,raw16,Erase_Count_Max/Avg "
     "-v 175,raw48,Bad_Cluster_Table_Count "
     "-v 192,raw48,Unexpect_Power_Loss_Ct "
   //"-v 194,tempminmax,Temperature_Celsius "
   //"-v 197,raw48,Current_Pending_Sector "
     "-v 229,hex48,Flash_ID "
-    "-v 235,raw48,Later_Bad_Block "
+    "-v 235,raw16,Lat_Bad_Blk_Era/Wri/Rea "
     "-v 236,raw48,Unstable_Power_Count "
     "-v 240,raw48,Write_Head"
   },

Notes:

This device is labelled on the outside as a D150QV-L, but reports as a D150QV - which is the family name, according to the spec sheet. Suffixes indicate powering and temperature variations

"235 - Later bad block" this is the count of bad blocks detected after leaving the factory and the mode they've tested faulty in. I'm not quite sure what order the write/read are in, as this was extracted from ismart documentation, but it appears to be correct.

"170 - badblock count" lists later_bad_blocks and the total including bad blocks from factory. The actual format is 0x64 0x64 0x00 0x00 [Total lsb msb] [later lsb msb] (Raw16 gives a bogus trailing zero)

"173 - erase count" has the max/avg order reversed from raw16(avg16) format. raw16 gives a bogus leading zero

attributes 9, 12, 168, 175 and 192 are set at raw48, but only the bottom 2 bytes are actually used (0x6464 lsb msb 0000 0000)

Bogons:

attribute 01 is fixed at 0x64 0x64 0xff 0xff 0xff 0x00 0x00 0x00

attribute 02, 03, 05, 07, 08, 10, 197 and 240 are all fixed at zeros.

attribute 194 has the usual temperature format, but byte 7 (the temperature) is never reported.

As such these could (and probably should!) all be filtered, particularly the reallocated and pending sector counts, as these will never move away from zero and that could be highly misleading to the casual observer (it certainly fooled our vendor!)

Comment:

I hope these help a bit. Trying to figure out what the "unknown attributes" really were was a bit of an adventure.

These devices are far more fragile than their 3000 cycle write duration indicates. They're optimised as read-only industrial controller drives (ie: don't write logs back to them and don't RAID1 them) but have been widely deployed as RAID1 boot pairs in production NASes (Certified by Nexenta, Open-E and ixSystems amongst other vendors) - where they break after a couple of years.

Thankfully they appear to be out of production, but even when they were sold there were higher-spec devices made by Innodisk - however getting hold of those devices was difficult as distributors took the attitude that "all models are the same".