我已经要求更换这么多 SSD，我不想再问了。但如果 SSD 确实坏了，仅仅一次服务器宕机就会让我损失 500 美元左右。
那么，如何确定SSD确实坏了呢？
我可以像在Windows中那样重新格式化硬盘吗？磁盘已挂载。
之前松动的引脚使服务器重新启动次数过多。看来它损坏了那里的所有SSD。
/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]#
badblocks -n -v在一个或多个分区上运行。我确信这在 SSD 上没有多大意义（块是虚拟的，SSD 有自己的坏块管理），但如果设备有问题，坏块进程可能会触发它们。
也就是说，如果badblocksSSD上发现了坏块，那么SSD就坏了。
我没有找到任何参考文献来支持这篇论文，但这是我的推理：
badblocks -n对整个分区进行低级读写测试。正如沃伦·杨（Warren Young）所说，这里很难证明是负面的，所以仅仅因为这个测试通过并不意味着驱动器没有损坏。
请注意，您必须首先卸载分区，这意味着如果您的根文件系统位于 SSD 上，您将必须使用 Live CD 或其他东西。
dmesg首先，按照我在上一个问题中建议的方式检查输出。如果内核在与驱动器通信时遇到问题，则会在那里报告。
这并不一定表明驱动器有问题。RAM 是另一个常见的罪魁祸首，因此请进行内存测试。我使用UBCD来实现此目的，但还有很多替代方案。
如果内存测试结果正常并且没有错误dmesg，但仍然出现 I/O 错误，则驱动器上可能存在坏扇区。要确定这一点，请在磁盘上运行fsck -c或。fsck -cc第一个测试对于 SSD 更好，因为它是只读测试，但它无法找到或修复与使用-cc.
最终，你无法证明负面的，所以你永远不能绝对自信地说“这个SSD没有坏”。
fsck更糟糕的是， （或）测试可能badblocks没有出现错误，但症状却消失了。这是因为现代可重写磁盘驱动器具有自我修复功能，当您可以向驱动器显示存在问题时，该功能就会启动。也就是说，此类设施通常会阻止您首先看到坏扇区的影响，因此，如果坏扇区确实是问题所在，则可能意味着驱动器的备用扇区池已用完。