Linux dm-crypt discard 与 SSD TRIM 的配置边界

在 Linux 的 LUKS/dm-crypt 加密卷上处理 SSD TRIM，先记住一个默认值：dm-crypt 默认忽略 discard 请求，不会主动把文件系统释放空间的信息传到底层设备。想让 TRIM 生效，必须同时满足“底层块设备支持 discard”和“加密映射允许透传”两个条件；但透传也会让物理设备更容易观察到文件系统类型、已用空间等信息。

官方资料：https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html

下面的命令用于建立检查思路，数值是现场采集项，不是本文预先给出的运行结果；配图是静态结构说明图，也不是某台机器的终端截图。

先把 discard 的设备链分清

一次 TRIM 相关请求通常要经过四个边界：文件系统产生 discard，映射设备决定是否透传，底层块设备报告可接受的 discard 范围，SSD 固件最终处理 TRIM。dm-crypt 的 allow_discards 参数只是允许请求通过加密层，并不等于下层设备一定支持，也不等于已经测得性能收益。

• 文件系统层：fstrim 或挂载策略产生释放空间的请求。
• dm-crypt 层：默认忽略 discard；启用 allow_discards 后才尝试透传。
• 块设备层：用 queue sysfs 的能力值表示最大范围和粒度。
• 安全层：透传模式可能暴露释放空间的时机和分布，降低部分使用痕迹的隐藏程度。

用设备能力指标判断是否具备 TRIM 条件

不要只看磁盘名称是否包含 SSD。先找到实际承载加密卷的底层设备，再查看它的 discard 能力；设备名和映射层要替换成现场值。

# 查看块设备、挂载点和 discard 相关摘要，避免把 mapper 名称当成物理盘
lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS,DISC-GRAN,DISC-MAX,DISC-ALN

# 读取底层块设备的硬件上限和软件上限；0 通常表示没有可用 discard 能力
cat /sys/block/nvme0n1/queue/discard_granularity
cat /sys/block/nvme0n1/queue/discard_max_hw_bytes
cat /sys/block/nvme0n1/queue/discard_max_bytes

discard_max_hw_bytes 是硬件单次可接受的上限，discard_max_bytes 是 Linux 使用的软件上限；后者可以被调低以避免过大的 discard 带来长延迟。若链路中还有 LVM、RAID、虚拟磁盘或其他 device-mapper 层，应逐层确认它们没有吞掉或改写 discard。

比较三种配置策略的性能和安全代价

实际选择可以先分成三档，而不是直接把 --allow-discards 写进所有机器的启动配置。

对 LUKS2，可以在打开映射时显式允许 discard；如果再使用 --persistent，激活标志会保存到元数据，后续激活也可能自动采用它。生产变更前应确认是否真的需要持久化，避免一次测试改变所有后续启动行为。

# 仅对本次打开的映射允许 discard；设备名和映射名请替换为现场值
sudo cryptsetup open /dev/nvme0n1p3 cryptdata --allow-discards

# 周期性回收的最小操作，输出可记录到运维日志中
sudo fstrim -v /mnt/data

# 查看当前映射状态，确认不要把普通挂载选项误认为 dm-crypt 参数
sudo cryptsetup status cryptdata

如果选择周期性 fstrim，可以把“回收字节数”和“命令耗时”作为两个最小指标，固定同一挂载点、相近工作负载和时间窗口后再比较。不要只拿一次输出宣称 SSD 更快；TRIM 常常影响的是后续写入和空间管理，收益还与控制器、预留空间和负载有关。

用可复查的指标做一次小型对比

指标驱动的比较重点不是追求一个固定数字，而是保证每次采集回答同一个问题：是否产生了 discard、请求被限制在哪里、调用耗时是否可接受。

# 记录文件系统本次可回收空间和命令耗时，避免只看“成功”二字
time sudo fstrim -v /mnt/data

# 再次记录块设备的上限，便于解释大范围 discard 是否被拆分
cat /sys/block/nvme0n1/queue/discard_max_bytes

# 用同一挂载点重复采集，先保留原始输出，不要手工改写数值
for i in 1 2 3; do
  echo "run=$i"; sudo fstrim -v /mnt/data
done

如果第一次回收量很大、后续接近零，这通常只能说明可回收空间已经被处理，不能直接推出持续写入性能提高。比较前还要固定文件系统、映射层、底层设备和工作负载；若中间存在虚拟机或云盘，应把云平台是否支持 discard 作为单独前提。

五个容易越过的边界

1. 把 --allow-discards 当成 SSD 检测开关：它只配置 dm-crypt 的透传行为，能力仍由下层链路决定。
2. 只看 /dev/mapper：映射层可能隐藏了真实设备的 discard 上限，必须回到底层 queue sysfs。
3. 忽略安全含义：内核和 cryptsetup 文档都提醒，discard 可能暴露文件系统类型、已用空间等信息。
4. 把 dm-integrity 当成普通 LUKS2：带数据完整性保护的认证模式不一定支持 discard，不能照搬普通映射参数。
5. 用一次耗时做性能结论：至少保留回收量、耗时、discard 上限和工作负载说明，才能解释差异来源。

常见问题

dm-crypt 默认为什么不透传 discard？

因为 discard 会让下层设备观察到释放空间的位置或模式，可能带来信息泄露风险。dm-crypt 默认忽略请求，把是否透传留给管理员按威胁模型决定。

周期性 fstrim 一定比持续 discard 更安全吗？

它通常更容易控制发生时机和记录窗口，但并不自动消除所有信息泄露；安全效果仍取决于频率、访问模式、设备链和攻击者能观察到的范围。

看到 discard_max_hw_bytes 非零就可以直接启用吗？

不可以。还要确认中间的 LVM、RAID、虚拟化层和 dm-crypt 参数能够把请求传下去，并核对是否使用了不支持 discard 的完整性保护模式。

参考资料

Linux dm-crypt 文档：https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html

Linux 块设备 ABI：https://docs.kernel.org/ABI/testing/sysfs-block

cryptsetup 手册：https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/man/cryptsetup.8.adoc