☰

文件系统（ext4）如何“存储”TRIM信息？

tag-icon • tag-icon ssd trim
文件系统（ext4）如何“存储”TRIM信息？

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

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

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

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

或者 fstrim 命令会比较文件系统和 SSD 来确定实际删除的数据吗？

答案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 本身真正知道当前修剪了什么，没有修剪什么，当被要求修剪已经修剪的区域时，它应该什么也不做。因此不会造成任何损害，也不需要真正将这些信息存储在文件系统中。

相关内容