☰

TRIM 是否需要“丢弃”安装？

tag-icon • tag-icon mount data-recovery ssd trim
TRIM 是否需要“丢弃”安装？

我想知道是否使用该选项安装SSD discard（记录在man mount）实际上需要将 ATA TRIM 发送到 SSD 的控制器。

证据有点间接：无论我是否discard在闪迪固态硬盘PLUS，删除后的文件无法通过立即运行 TestDisk 来恢复。文件路径完好无损，但文件内容消失了。由此我怀疑 TRIM 在 SSD 上运行并导致文件内容无法恢复。

看了一下systemctl list-timers，好像没有一个运行的单位fstrim。

尽管分区未挂载，但文件删除后内核是否会发送 TRIM discard？或者这是 TestDisk 无法可靠地从 SSD 恢复文件的另一个原因？

我使用的是 Arch Linux 5.12.3。

findmnt告诉我有关分区及其安装选项的信息：

TARGET                       SOURCE     FSTYPE OPTIONS
/                            /dev/sda3  ext4   rw,relatime
└─/sda1                      /dev/sda1  ext4   rw,relatime,lazytime,discard

答案1

如果文件系统使用 挂载discard，则删除文件将自动导致发出 TRIM 命令。这通常会对性能产生负面影响，因此通常最好不要使用该挂载选项，而是fstrim定期运行，只要所有块设备层都支持它就可以工作（例如，如果您使用 LUKS 进行加密，你需要使用cryptsetup --allow-discards）。除非您使用此挂载选项，否则当您取消链接文件时，文件系统驱动程序不会自动发送 TRIM 命令。

您也可以尝试使用 进行安装nodiscard。尽管这是默认设置并且通常是不必要的，但您的文件系统可能已将连续的 TRIM 支持添加到通过tune2fs -o discard /dev/sda1.您可以使用 删除它tune2fs -o ^discard /dev/sda1。

debugfs您可以使用该实用程序在删除文件之前首先列出文件中的实际块，然后在删除后直接访问这些块以查看它们是否已归零或返回未受干扰但未分配的数据，从而找出问题所在。

下面是一个 shell 脚本，用于测试是否debugfs可以使用块号读取已删除文件的内容：

#!/bin/sh

file=test_file
echo "Current date: $(date)" > "$file"; sync
# Get the device of our test file, for example "/dev/sda1"
device=$(df -P "$file" | awk 'END{print $1}')
# The block of the file's contents, stat gets the inode number
block=$(sudo debugfs -R "blocks <$(stat -c %i "$file")>" "$device")
rm $file; sync
# Read the contents of the deleted file, -D bypasses the buffer cache
sudo debugfs -D -R "block_dump $block" "$device"

相关内容