Archlinux 上的 SSD Trim

Archlinux 上的 SSD Trim

我听到了很多关于 SSD Trim 的不同意见,通常知道如何处理它并不是很重要,因为你知道它是如何处理的,除非我使用的系统大多数安装步骤都是手动的,比如 Arch Linux。

Arch Linux 文档确实解释了配置 SSD 修剪的几种方法,连续、定期……等等,但它并没有说明内核是否在支持的文件系统上默认进行修剪而无需任何额外的配置步骤。

我可以安全地跳过文档中提供的连续或定期修剪的手动配置吗?如何监控这些类型的操作?如果不使用文档中解释的任何方法,使用内核 5+ 和 ext4 作为 fs 进行全新安装是否安全?

https://wiki.archlinux.org/index.php/Solid_state_drive)?

当 Arch Linux 长期默默地假装健康时,我从未修剪过 SSD 磁盘,因此我是否应该长期担心?

答案1

内核仅有的在两种情况下发出丢弃操作:

  1. 定期:当fstrim工具要求时。

  2. 持续:每当文件被删除时,如果文件系统已使用该discard选项挂载。默认情况下,此选项处于禁用状态。

第二种选择通常会被避免,因为它是同步的——大多数文件系统每次都会等到丢弃完成,这使得同步写入磁盘相当慢因为丢弃并不是一个快速的操作。(异步丢弃仅存在于 XFS 和最近在 Btrfs 中。)我还想象不必要的频繁丢弃操作对 SSD 寿命也没有太大帮助。

(更重要的是,你可以在链接的文章中看到一条通知,一些较旧的基于 SATA 的 SSD 不支持“排队”TRIM,这意味着所有操作– 即使读取 – 也必须等到 TRIM 请求完成其工作。)

因此,大多数系统选择第一个选项,fstrim -Av每周左右安排一次。这通常使用“fstrim.timer”systemd 单元完成。每次调用时,fstrim 服务都会写入 syslog:

$ journalctl -u fstrim

Feb 07 19:18:23 fstrim[401]: /: 484.5 GiB (520173604864 bytes) trimmed on /dev/sdb3

如果您选择完全不使用 TRIM,您的 SSD 就不会起火(即使它是由三星制造的);只有当它认为 100% 的磁盘正在使用中时,它接受写入的速度才会变得稍微慢一些。

(也就是说,即使从未使用 TRIM,新的 SSD 似乎也有足够的备用空间来继续正常工作,但我还没有做过或寻求过任何研究来了解这会如​​何影响它们的性能,这只是我的一般猜测。)

请注意,如果您使用的是 LVM 或 cryptsetup,则所有这些层都需要配置为将丢弃操作传递到下层。默认情况下,cryptsetup忽略丢弃操作,因为它优先考虑隐私而不是性能——TRIM 本质上揭示了哪些磁盘区域正在使用以及哪些是空闲的。

相关内容