java - 重复写入/删除 SSD 的风险？

Question

我有一个 Java 程序，它创建一个大小约为 1K 的日志文件。如果我运行一个删除旧日志的测试，并创建一个新日志，然后保存它，重复一百万次，如果文件的大小随着时间的推移而增长（高达几 MB），我是否会冒损坏我的 SSD 的风险? 日志文件是否有可以避免这种风险的大小限制，或者任何人都可以帮助我了解风险的机制吗？

Answer 1

在不断打开/关闭相同文件并逐渐增加文件大小的情况下，文件系统和 SSD 级别有 2 种保护机制可以防止早期磁盘故障。

首先，在每次删除文件时，文件系统都会向 SSD 发起 Trim（又名 Discard aka Logical Erase）命令。修剪地址范围将覆盖整个删除文件的大小。Trim 极大地帮助 SSD 为新数据回收可用空间。在访问相同的数据范围时，将 Trim 与 Writes 结合使用是 SSD 节省其耐用性的最佳操作模式。只需确保您的操作系统启用了修剪操作（通常是默认设置）。所有现代 SSD 也应该支持它。重要提示，Trim 是逻辑擦除，它不会立即启动物理介质擦除。物理擦除稍后将作为 SSD 内部垃圾收集的一部分间接启动。

其次，当访问同一个文件时，文件系统很可能会在同一个地址向 SSD 发出写入。只是写入量会随着文件大小的增加而增加。这种模式称为热范围访问。就耐用性而言，对于 SSD 来说，这是一种令人讨厌的模式。SSD 必须在每次文件写入时分配空闲资源（物理页面），但数据的生命周期非常短，因为数据几乎立即被删除。总体而言，SSD 物理介质中的唯一数据量非常少，但分配和处理的资源（物理页面）量很大。现代 SSD 通过以循环方式使用物理介质单元来防止热范围访问，从而均衡磨损。

我建议监控 SSD SMART Health Data（Life-time left 参数），例如使用https://www.smartmontools.org/或 SSD Vendor 提供的软件。我将帮助您了解您的访问模式如何影响耐力。

Answer 2

与任何文件一样，如果磁盘没有足够的空间来写入文件，操作系统（或 Java）将不允许写入文件，直到空间被清除。以这种方式“搞砸”磁盘的唯一方法是在内核级别弄乱地址。