文件系统 (ext4) 如何“存储”TRIM 信息？

Question

建议启用每周运行一次的 TRIM cron 作业。当调用 fstrim 命令时，文件系统会将 TRIM 信息发送到驱动器以丢弃已删除的数据（我希望我做对了）

到目前为止一切顺利，这在很多地方都有描述。

但是我找不到任何关于这些 TRIM 信息如何/在哪里“存储”在 fstrim 命令之间的文件系统中的信息？

并且可以以某种方式“清除”这些 TRIM 信息，以便 SSD 不会获得所有必须丢弃的页面/块的信息？

或者 fstrim 命令会比较文件系统和 SSD 哪些数据实际上被删除了？

Answer 1

我不知道 ext4 是否真的将它存储在任何地方。其他文件系统当然不会。

ext4 仅避免在当前会话中已修剪的内容 - 当它仍处于安装状态时。一旦您重新启动或重新挂载文件系统，它只会再次修剪空白空间。

所以这可能是一个根本不存储的内存结构。我没有深入研究非常好的源代码来找出答案。

一个小测试：

# truncate -s 1G /dev/shm/foobar.img
# losetup --find --show /dev/shm/foobar.img
/dev/loop9
# mkfs.ext4 /dev/loop9
# mkdir /mnt/loop

给定一个 1G 的文件系统，让我们挂载和修剪它：

# mount /dev/loop9 /mnt/loop/
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed
# fstrim -v /mnt/loop
/mnt/loop: 0 B (0 bytes) trimmed

所以它首先修剪所有......毕竟这已经是可疑的：mkfs也已经修剪过（哎哟），所以它应该知道它仍然是空的并且修剪过，对吧？好吧，如果它知道，它不在乎：

# umount /mnt/loop
# mount /dev/loop9 /mnt/loop
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed

因此，重新安装后，它只会再次修剪所有可用空间。

创建和删除文件时，也不是精确定位：

# dd bs=1M count=10 if=/dev/zero of=/mnt/loop/zerofile
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0124641 s, 841 MB/s
# sync
# rm /mnt/loop/zerofile
# fstrim -v /mnt/loop
/mnt/loop: 117.5 MiB (123203584 bytes) trimmed

因此，写入 10M 会导致重新修剪 117M。它只是没有任何意义。

只有 SSD 本身真正知道哪些是当前修剪的，哪些未修剪，并且当被要求修剪已经修剪的区域时，它应该什么都不做。因此不会造成任何伤害，也无需将这些信息真正存储在文件系统中。