Opened 7 months ago

Closed 2 months ago

Last modified 6 weeks 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 7 months ago.
ksm-smart-export-KINGSTON-DC500.txt (9.4 KB) - added by Matthew Eaton 7 months ago.

Download all attachments as: .zip

Change History (18)

Changed 7 months ago by Matthew Eaton

Attachment: smartctl-KINGSTON-DC500.txt added

Changed 7 months ago by Matthew Eaton

comment:1 Changed 7 months ago by Christian Franke

Keywords: ssd added

comment:2 Changed 6 months ago by Matthew Eaton

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 Changed 2 months ago by Christian Franke

Owner: set to Christian Franke
Status: newaccepted

comment:4 Changed 2 months ago by Christian Franke

Resolution: fixed
Status: acceptedclosed

comment:5 Changed 2 months ago by Matthew Eaton

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 Changed 2 months ago by Matthew Eaton

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

comment:7 in reply to:  5 Changed 2 months ago by Christian Franke

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 Changed 2 months ago by Christian Franke

comment:9 Changed 2 months ago by Christian Franke

Resolution: fixed
Status: acceptedclosed

comment:10 Changed 6 weeks ago by yhemery

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 Changed 6 weeks ago by Matthew Eaton

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 Changed 6 weeks ago by Matthew Eaton

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 Changed 6 weeks ago by yhemery

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 Changed 6 weeks ago by Matthew Eaton

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 Changed 6 weeks ago by Matthew Eaton

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 Changed 6 weeks ago by yhemery

Ok, thanks for taking the time to check that.

Note: See TracTickets for help on using tickets.