在 RHEL 上排查存储性能或空间回收问题时，fstrim 定期回收是否正常运行经常被忽略。很多管理员以为只要启用 fstrim.timer 就万事大吉，但实际上 timer 的 active 状态并不代表 TRIM 命令已经成功执行。要判断回收是否有效，必须同时检查定时器触发记录、fstrim.service 的执行结果以及底层挂载参数是否真正支持 discard。
fstrim 的作用是把文件系统中已经被释放的块通知给存储设备，让 SSD 控制器或者精简置备阵列能够回收这些物理空间。RHEL 7 及以上版本默认提供 fstrim.timer，但这个 timer 在部分环境中会被手动禁用，或者因为挂载选项写入了 discard 而被认为不需要 timer。实际上 discard 挂载选项是同步 TRIM，每次删除文件都会触发设备命令，开销较大；而 fstrim.timer 是异步批量 TRIM，更适合生产环境。理解这一差异有助于后续故障判断。
先确认 fstrim.timer 是否真的在按计划运行
第一步不是直接执行 fstrim，而是查看 systemd 定时器的状态。使用 systemctl status fstrim.timer 可以看到定时器是否处于 active (waiting) 状态。很多故障案例中，timer 被 enable 了，但上次触发时间已经过去好几天甚至更久，这说明定时器没有按计划唤醒。需要进一步查看 systemctl list-timers fstrim.timer 的输出，确认 NEXT 和 LAST 字段。
如果 LAST 字段显示 n/a，说明这个 timer 从未成功触发过。可能的原因包括：系统在计划触发时间点处于关机状态、systemd 定时器单元被 masking、或者 Persistent 参数缺失导致错过的触发不会补跑。对于服务器通常长期运行，但维护窗口后经常出现这类问题。可以执行 systemctl cat fstrim.timer 查看 OnCalendar 配置和 Persistent 设置。
# 查看定时器状态与触发历史 systemctl status fstrim.timer systemctl list-timers fstrim.timer # 查看单元文件内容 systemctl cat fstrim.timer # 手动测试触发一次 sudo systemctl start fstrim.service
手动执行 systemctl start fstrim.service 是验证服务本身是否正常的最快方式。如果手动执行成功但定时触发失败，问题在 timer 配置或系统电源状态；如果手动执行也报错，则需要进入命令和存储层排查。注意手动启动 fstrim.service 不等于启动 timer，两者是独立的 systemd 单元。
从 fstrim 命令报错定位存储层问题
当 fstrim.service 执行失败时，journal 日志会记录具体错误。使用 journalctl -u fstrim.service 查看最近一次执行输出。常见报错包括 fstrim: <挂载点>: the discard operation is not supported，这表示该文件系统或底层设备没有向操作系统暴露 TRIM 能力。即使 SSD 本身支持 TRIM，经过 LVM、dm-crypt、RAID 控制器时，如果这些中间层没有配置透传，fstrim 也会失败。
对于 LVM 场景，需要检查 /etc/lvm/lvm.conf 中的 issue_discards 参数。在精简置备池中，如果 issue_discards 为 0，删除逻辑卷后空间不会归还给池，也会导致后续 fstrim 看似执行但实际没有效果。对于加密层，需要确认 crypttab 中是否加入了 discard 选项。排查思路是先确定文件系统层面是否支持 TRIM，再逐层向下检查设备映射关系。
# 查看 fstrim 服务最近日志 journalctl -u fstrim.service -n 30 --no-pager # 检查指定挂载点是否支持 TRIM sudo fstrim -v /data # 查看块设备是否支持 discard lsblk -D /dev/sda # 查看 LVM 配置中 issue_discards 是否开启 grep issue_discards /etc/lvm/lvm.conf
lsblk -D 命令中的 DISC-GRAN 和 DISC-MAX 字段如果不为 0，说明该设备支持 discard。如果为 0B，说明设备或控制器没有暴露 TRIM 能力。在虚拟机环境中，还需要检查虚拟磁盘类型是否为精简置备，并且虚拟机配置中是否允许 guest 发送 TRIM 命令。很多虚拟化平台默认关闭了 guest TRIM，需要手动开启。
如果 fstrim -v /data 返回 the discard operation is not supported，而硬盘本身是 SSD，可以先查看挂载选项。使用 findmnt /data 查看当前挂载参数中是否有 discard 或 nodiscard。注意 fstrim 命令本身不依赖 discard 挂载选项，它会直接向内核发送 TRIM 请求，所以即使挂载时使用 nodiscard，fstrim 也应当可以工作。如果 fstrim 仍然失败，问题通常出在更底层。
修复 fstrim 定期回收的配置与验证
确定故障原因后，修复方式分为几种情况。如果是 timer 未启用或未持久化，直接执行 systemctl enable --now fstrim.timer 即可。但要注意，如果之前手动禁用过 timer，可能需要先重置 systemd 的 disable mask。如果希望调整执行频率，不要直接编辑 /usr/lib/systemd/system/fstrim.timer，应该使用 systemctl edit 创建 override 文件，例如设置 OnCalendar=weekly 和 Persistent=true。
对于底层不支持 TRIM 的情况，不能只靠启用 timer 解决问题。需要根据实际存储路径逐层开启 discard 透传。例如在 /etc/lvm/lvm.conf 中将 issue_discards 设为 1，在 crypttab 的选项列加入 discard，在虚拟机配置中启用 guestTrim。修改后重启相关服务或重新挂载文件系统，再执行 fstrim -v /挂载点 验证是否返回回收的字节数。如果返回如 /data: 12.3 GiB trimmed，说明 TRIM 已经成功下发给设备。
# 启用并立即启动 fstrim.timer sudo systemctl enable --now fstrim.timer # 创建 override 调整执行频率 sudo mkdir -p /etc/systemd/system/fstrim.timer.d printf '[Timer]\nOnCalendar=weekly\nPersistent=true\n' | sudo tee /etc/systemd/system/fstrim.timer.d/override.conf sudo systemctl daemon-reload # 开启 LVM 的 discard 支持 sudo sed -i 's/^[[:space:]]*#*[[:space:]]*issue_discards[[:space:]]*=.*/issue_discards = 1/' /etc/lvm/lvm.conf # 验证 fstrim 是否真正回收 sudo fstrim -v /data
验证环节不能只看命令退出码，还要关注输出中 trimmed 的字节数。如果输出为 0 B trimmed，说明文件系统当前没有可回收的块，不代表故障，但如果在删除大量文件后仍然为 0，则需要检查文件系统是否真的执行了 TRIM，以及是否被某些缓存或快照影响。对于 XFS 和 ext4，默认行为略有差异，XFS 在创建时如果指定了 -o discard 以外的选项，不会影响后续 fstrim 的使用。
监控方面，可以通过 systemd 的日志定期检查 fstrim.service 的执行记录，也可以写一个简单的 cron 或 systemd timer 来记录每次回收的空间大小。不要依赖 mount | grep discard 判断 TRIM 是否生效，因为在 RHEL 中 fstrim.timer 的场景下，挂载选项完全可以保持为 nodiscard。真正需要关注的是 fstrim 命令的返回值以及块设备层的 discard 支持状态。把这几层都排查清楚，fstrim 定期回收的故障基本都能定位并解决。