Custom Query (1364 matches)

Please add SAMSUNG MZ7KM960HMJP SSD to drive database.

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".

I've bought a brand new 1T Seagate drive yesterday.

kotik tmp # dmesg | grep ST31
[    0.834822] ata1.00: ATA-8: ST31000528AS, CC35, max UDMA/133
[    0.847168] scsi 0:0:0:0: Direct-Access     ATA      ST31000528AS     CC35 PQ: 0 ANSI: 5

I was quite surprised to see its Head_Flying_Hours to be some n-teen digit number when I first run smartctl on it, however, Power_On_Hours value was sane. To be sure that everything is ok with my eyes I ran smrtctl again. This time the value was completely different although of the same order of magnitude. After quick investigation it became quite obvious that there is something wrong with the byte order of the raw value

kotik tmp # smartctl -d ata  -A  /dev/sda  | grep ^240
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       102838696935451
kotik tmp # printf "%x\n" 102838696935451
5d880000001b

When I read the values with my programme (see attachment) I found that one of the bytes of the value is stored in the reserv field of the ata_smart_attribute structure. The right order to read the value seems to be

raw[3], raw[2], raw[1], raw[0], reserv, raw[5], raw[4]

However, I am not sure about more significant bytes (raw[1-3]).

The value itself is almost for sure number of milliseconds.