2

This question already has an answer here:

Is my SSD broken?

I have asked to replace so many SSD I don't feel like asking it again. But if the SSD is indeed broken, just one time server down will cost me $500 or something.

So, how do I make sure that the SSD is indeed broken?

Can I just reformat hard disk like in windows? The disk is mounted.

Before a loose pin make the server reboot too many times. It seems that it damaged all SSD there.

/bin/ls: cannot access cache-zch-5666-cache.txt: Input/output error
/bin/ls: cannot access cache-zch-4970-cache.txt: Input/output error
/bin/ls: cannot access cache-zch-4782-cache.txt: Input/output error
./   cache-zch-4782-cache.txt  cache-zch-5666-cache.txt
../  cache-zch-4970-cache.txt
root@host [/home2/investgr1/public_html/hello/cache/zch]# rm *
rm: cannot remove `cache-zch-4782-cache.txt': Input/output error
rm: cannot remove `cache-zch-4970-cache.txt': Input/output error
rm: cannot remove `cache-zch-5666-cache.txt': Input/output error
root@host [/home2/investgr1/public_html/hello/cache/zch]#
|improve this question

marked as duplicate by Anthon, slm♦, terdon♦, rahmu, jasonwryan Oct 5 '13 at 18:33

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Is that a SATA SSD? Isn't that able for a hotplug? – ott-- Oct 5 '13 at 14:11
2

First, check the output of dmesg as I suggested in your previous question. If the kernel is having problems talking to the drive, it will be reported there.

That doesn't necessarily indicate the drive is bad. RAM is another popular culprit, so do a memory test. I use UBCD for this, but there are many alternatives.

If the memory test comes up clean and there are no errors in dmesg, but you're still getting I/O errors, you likely have bad sectors on the drive. To determine that, run fsck -c or fsck -cc on the disk. The first test is better for SSDs, since it's a read-only test, but it can't find or fix as many problems as the read-then-write test you get with -cc.

Ultimately, you can't prove a negative, so you can never say "This SSD is not broken," with absolute confidence.

Making the problem worse, it is possible for an fsck (or badblocks) test to come up with no errors, but for the symptom to go away. This is because modern rewritable disk drives have self-repair facilities that kick in when you can show the drive that there is a problem. That said, such facilities usually prevent you from seeing the effect of bad sectors in the first place, so if bad sectors are indeed the problem, it can mean the drive's pool of spare sectors is used up.

|improve this answer
  • 3
    badblocks is probably not the best tool to unleash on an SSD as internally, the a read-write cycle of a single (small 512 Byte) badblocks level-block will cause the SSD to reallocate/erase a large (512 KiB) SSD-level block again and again, leading to excessive wear and tear (See The Anatomy of an SSD. One should probably set the blocksize: badblocks -b 524288. A supersimple test is trying to read the entire SSD using dd if=/dev/sda of=/dev/null. There may be vendor-specific tools too, check the Internet. My Samsung diagnostics didn't bark though. – David Tonhofer Apr 2 '16 at 16:43
  • @DavidTonhofer: do you know how to determine the appropriate block-size for a specific SSD if a badblock test is needed after all? See this question/comment for background. – sxc731 Nov 14 '17 at 10:42
  • @sxc731 No, sorry. – David Tonhofer Nov 14 '17 at 22:32
2

Run badblocks -n -v on one or more of the partitions. I'm sure this is not that meaningful on an ssd (the blocks are virtual, and ssd's do their own bad block management), but if the device has problems, the badblock process may trigger them.

Which is to say, if badblocks finds bad blocks on an SSD, the SSD is broken.

I have not found any references to back up this thesis, but here's my reasoning:

  • badblocks -n does a low level read-write test of the entire partition.
  • SSDs manage their own bad blocks internally and also use wear levelling to distribute use; the block addresses sent to the system are virtual. Therefore, none of those blocks should test bad, and if they do, some functioning of the drive has failed.

As Warren Young says, it's hard to prove a negative here, so just because this test passes does not mean the drive isn't broken.

Note that you must unmount the partitions first, meaning you'll have to use a live CD or something if your root filesystem is on the SSD.

|improve this answer

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