With the traditional spinning disks diagnostics is rather easy. If you suspect a drive to be faulty, you can check the SMART values, run a SMART extended test and a badblocks -wsv test. If all three tests show no error, the drive is probably/usually fine.

What should we do in case of SSDs or modern NVMe drives?

Obviously, SMART is still a good idea, but what if it complets without error? Is running badblocks -wsv on a flash-based memory device a good idea?

Are there other options?

Also, if using badblocks what options are suitable? Should one use the "erase block size" of the SSD?

This question is similar to Can I prove that an SSD is broken? But the answers there are from 2013. We have seen several generations of flash technologies since then. - Also, while they suggest badblocks, I am missing a discussion on weather this is a good idea at all. Ultimatley, some flash memories do not like it to be written to a 100%. Also, how do we tell the SSD afterwards which sectors are free (again)?

How to fix bad blocks on SSD is also not satisfying.

How safe is it to run CHKDSK on an SSD? discusses only the impact of chkdsk

I could not find other resources that deal with this problem.

  • I don't see the reason approaches to validate the health status of a SSD would change. Individual cell write limitations still exist or more importantly are not at levels which make it impossible for them to be reached. So the same approaches can be used even with the newer products. – Ramhound Nov 8 '17 at 22:01
  • 1
    But is it a good idea or might I damage the ssd with badblocks? I edited the question to include the "erase block size". Because if I run badblocks an it uses 512k blocks, then every cell will be written a dozen times. – masgo Nov 8 '17 at 22:15
  • I would argue that running badblocks on a SSD was never useful/meaningful, and even the author of the linked answer, indicated that was the case. – Ramhound Nov 8 '17 at 22:39
  • 1
    Your question makes good sense IMHO. I've just had a Samsung SSD loose data due to bad blocks. I secure erased the drive and SMART extended tests now say it's fine (SMART attributes Used_Rsvd_Blk_Cnt_Tot=68 out of Unused_Rsvd_Blk_Cnt_Tot=17503, Wear_Leveling_Count is low). So on the surface this SSD looks fine but I'd like to do more testing before recommissioning the drive! IMHO this comment points in the right direction but how do you determine appropriate SSD-level block size? – sxc731 Nov 14 '17 at 10:30
  • 1
    I saw another post on how to determine the blocksize. You basically do write-speed tests with different sizes and look where the speed changes. You could also go ahead an just use 4MB blocks. This will probably guarantee you to be above the block size. If you get an error the shown "sector" will not help much, but at least you know there is an error. – masgo Nov 14 '17 at 11:18

In general, you shouldn't need to, beyond paying attention to what SMART is already telling you. The reason is that SSDs use wear leveling, so they have an advanced controller that already takes care of detecting and re-mapping bad blocks in the background, so from the OS's perspective, and the perspective of standard utilities like badblocks, any blocks that went bad are invisible because they've already been remapped. If badblocks somehow did find a block that was bad, it would be immediately remapped and thus would be "good" again the next time you read it.

To really get an indication of the health of your drive, what you need to know is how many bad blocks the controller has already remapped, and how much spare capacity remains to allow it to remap further. SMART data should give you this for SATA, or NVMe has equivalent log pages that contain the same information. In particular, the 'Available Spare' attribute will give you a percentage of how much of the drive's total remapping capability has been used up.

This page has some specific command line tools you can use for SATA or NVMe: https://www.percona.com/blog/2017/02/09/using-nvme-command-line-tools-to-check-nvme-flash-health/

  • 1
    I know my question is old, but I still have not found a good answer. While your answer is true for many errors, relying on SMART alone is not enough. For example: I had one SSD with a broken DRAM modules (probably). It had a very strange behaviour which occured only occasionaly under high load. I used 'badblocks' with 'last_block' parameter to limit it to 75% of the capacity. It found errors in the first run and different errors in the second run. Therefore I decided this SSD was broken. – masgo Nov 24 '20 at 12:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.