普通用户程序无法直接读取SSD的TRIM指令记录，因TRIM是主机发出的告知性命令，消费级SSD硬件不保存其时间、LBA范围或执行次数等日志；厂商工具显示的“TRIM已启用”仅反映系统配置状态，而非设备侧执行记录；Linux下可通过dmesg、/sys/block/xxx/queue/discard_*等验证内核与文件系统是否发出TRIM，但无法从SSD读取原始指令日志。
普通用户程序无法直接读取 SSD 的 TRIM 指令记录。
TRIM 指令本身不被 SSD 记录为可查询日志
TRIM（ATA_CMD_TRIM 或 NVMe DEALLOCATE）是主机向 SSD 发出的“告知性”命令，用于标记逻辑块不再有效。它不触发数据读取，也不要求设备返回执行详情——绝大多数消费级 SSD 硬件根本不保存 TRIM 的时间、LBA 范围或次数等信息。厂商工具（如 Samsung Magician、Intel MAS）显示的“TRIM 已启用”或“优化完成”，只是检查操作系统是否配置了定期 fstrim 或启用 discard 挂载选项，并非读取了设备侧日志。
Linux 下能查到的只有内核/文件系统层的 TRIM 行为痕迹
你可以验证 TRIM 是否被发出，但不是从 SSD 读，而是看内核和文件系统有没有调用它：
-
dmesg | grep -i trim可能显示 ATA/NVMe 驱动接收 TRIM 命令的日志（需内核开启CONFIG_ATA_DEBUG或CONFIG_NVME_DEBUG，且通常默认关闭） -
cat /sys/block/nvme0n1/queue/discard_granularity和/sys/block/nvme0n1/queue/discard_max_bytes确认设备是否支持 discard（非记录，仅能力） - 挂载时加
discard选项后，用strace -e trace=ioctl -p $(pidof your_app)捕获应用是否触发BLKDISCARD系统调用（仅限显式调用，如fstrim）
NVMe 设备的有限诊断入口：log page 02h（SMART/Health）
NVMe 规范定义了 log page 02h，其中部分字段（如 num_unmap_cmds）理论上可统计 UNMAP（TRIM 对应的 NVMe 指令）执行次数。但实际支持度极低：
立即学习“C++免费学习笔记（深入）”；
- 多数主控（Phison、SMI、InnoDisk）不实现该计数器，读出来恒为 0
- 即使有值，也仅是累计整机上电后的粗略计数，无时间戳、无 LBA 范围、不可清零
- 读取需 root 权限 +
nvme get-log工具：sudo nvme get-log /dev/nvme0 -l 2 -H；C++ 中需用ioctl(NVME_IOCTL_ADMIN_CMD)构造并提交 log page 获取命令，参数复杂且易出错
真正想定位 TRIM 效果？别盯指令记录，看实际表现
TRIM 的价值体现在后续写入延迟下降和空间回收效果上：
- 用
hdparm --fibmap查某个文件物理位置，删掉再fstrim，观察同一文件重写时的iostat -x中await是否降低 - 填满盘后顺序写入大文件，对比开启/关闭
discard时的稳定态写入速度（需避开缓存干扰） - 用
smartctl -a /dev/sdX查看Media_Wearout_Indicator或Available_Reserve_Space变化趋势——长期未 TRIM 可能加速预留空间耗尽
硬件层面没有“TRIM 日志”这个东西，所有声称能读它的方案，要么是误读 SMART 字段，要么是混淆了主机侧调度痕迹与设备侧执行记录。真要调试，优先确认 OS 层是否发出了命令，再结合性能指标反推效果。
