Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#1176 closed enhancement (fixed)

Add to drivedb: Kingston DC500R / DC500M

Reported by: Matthew Eaton Owned by: Christian Franke
Priority: minor Milestone: Release 7.1
Component: drivedb Version: 7.0
Keywords: ssd Cc:

Description

Request to add Kingston DC500R and DC500M drive families to drivedb.

Model numbers:
KINGSTON SEDC500R480G
KINGSTON SEDC500R960G
KINGSTON SEDC500R1920G
KINGSTON SEDC500R3840G
KINGSTON SEDC500M480G
KINGSTON SEDC500M960G
KINGSTON SEDC500M1920G
KINGSTON SEDC500M3840G

Data sheet:
https://www.kingston.com/datasheets/DC500R_us.pdf

SMART attributes sheet:
https://media.kingston.com/support/downloads/MKP_521_Phison_SMART_attribute.pdf

Attachments (2)

smartctl-KINGSTON-DC500.txt (9.4 KB ) - added by Matthew Eaton 5 years ago.
ksm-smart-export-KINGSTON-DC500.txt (9.4 KB ) - added by Matthew Eaton 5 years ago.

Download all attachments as: .zip

Change History (18)

by Matthew Eaton, 5 years ago

Attachment: smartctl-KINGSTON-DC500.txt added

by Matthew Eaton, 5 years ago

comment:1 by Christian Franke, 5 years ago

Keywords: ssd added

comment:2 by Matthew Eaton, 5 years ago

Link to SMART attributes sheet specific to DC500 series: https://media.kingston.com/support/pdf/MKP_521-7_SMART-DC500_attribute_hr.pdf

comment:3 by Christian Franke, 5 years ago

Owner: set to Christian Franke
Status: newaccepted

comment:4 by Christian Franke, 5 years ago

Resolution: fixed
Status: acceptedclosed

comment:5 by Matthew Eaton, 5 years ago

Resolution: fixed
Status: closedreopened

Thank you! But there are a couple of incorrect attribute names below. The rest look good.

  1. 194 should be Temperature
  2. 195 should be Power Fail Health

comment:6 by Matthew Eaton, 5 years ago

FYI, the unknown attributes (167, 169, 172, 181, 182) are covered here:
https://media.kingston.com/support/pdf/MKP_521-7_SMART-DC500_attribute_hr.pdf

in reply to:  5 comment:7 by Christian Franke, 5 years ago

Status: reopenedaccepted
  1. 194 should be Temperature
  2. 195 should be Power Fail Health

Indeed, a typo in one attribute number invalidated both. Thanks for catching.

FYI, the unknown attributes (167, 169, 172, 181, 182) are covered here:

Will add these also, thanks.

comment:8 by Christian Franke, 5 years ago

comment:9 by Christian Franke, 5 years ago

Resolution: fixed
Status: acceptedclosed

comment:10 by yhemery, 5 years ago

Hello,

I tried to use the trunk version of drivedb.h on a SEDC500M960G, but it looks like there are two minor issues related to the bad blocks counters :

  • On attribute AAh, the byte mask changed on the DC500 :

DC400 :

Raw Value Byte [1~0]: Early bad block count
Raw Value Byte [5~4]: Later bad block count

DC 500 :

Raw Value Byte [3~0]: Early bad block count
Raw Value Byte [5~4]: Later bad block count

Currently, the both use the same mask (z54z10).

  • Attribute C4h is unused on the DC400, and used as "Total Later Bad Block Count" on the DC500. On the DC500 I tested, the attribute is incorrectly interpreted as "Reallocated_Event_Count" (Default value for this attribute).

I may create another ticket if you prefer.

comment:11 by Matthew Eaton, 5 years ago

I'm unsure on the byte mask issue you brought up. Maybe Christian can clarify on that point?

For attribute 196 it does count later bad blocks, but a later bad block triggers a reallocation event as well. So "Reallocated_Event_Count" is not technically incorrect.

comment:12 by Matthew Eaton, 5 years ago

Now I think I see what you mean regarding byte mask.

I think byte 3~0 is an error in our SMART document and it should be 1~0. I will confirm with our engineering.

comment:13 by yhemery, 5 years ago

Ok for the byte mask, thanks for checking.

About the attribute 196 : Most of the definitions I found for the "Reallocated_Event_Count" seems to describe it as the number of attempts by the firmware to move data from a defective block to a safer place : It might end up with a different value than the bad block count if the firmware perform more than one reallocation attempt, unless I'm mistaken ?

comment:14 by Matthew Eaton, 5 years ago

I see what you're saying and that might be true for another drive manufacturer. Unlike NVMe there is no standard set for SMART attributes for SATA.

The way I understand it is the drive internally keeps track of used spare blocks so logically it wouldn't try to reallocate a bad block to a used/bad spare block and then try again.

comment:15 by Matthew Eaton, 5 years ago

I heard back from our engineering regarding attr 170:

Since bytes 3~2 will be zero anyway, the documentation is still accurate and future-proof.

So I think we are good until a future drive makes use of bytes 3~2.

comment:16 by yhemery, 5 years ago

Ok, thanks for taking the time to check that.

Note: See TracTickets for help on using tickets.