journal模式慢在写入需两次强制落盘（日志+数据），随机小写吞吐降至bitmap的1/3～1/2；bitmap快因绕过双重i/o、仅读时校验，但崩溃一致性弱、无恢复机制。
journal 模式到底慢在哪？
journal 模式在写入时必须先将数据和校验元信息（integrity_tag）同步落盘到日志区域，再更新主数据区。这意味着一次普通写会触发至少两次磁盘 I/O：一次 journal write + 一次 data write，且 journal write 是强制 fsync() 的——哪怕你用 dd oflag=direct，内核仍会在 dm-integrity 层拦截并刷日志。
- 随机小写（如数据库 WAL、ext4 journal）延迟飙升明显，实测 4K 随机写吞吐可能跌至 bitmap 模式的 1/3～1/2
- journal 区域本身需预留空间（默认 128MB），且不能动态收缩；若设备空间紧张，
dmsetup create会静默失败或报Device or Resource busy - journal 不支持 TRIM，SSD 上长期运行后垃圾回收压力更大，实际性能衰减比 bitmap 更快
bitmap 模式为什么看起来“快”，但校验更弱？
bitmap 模式不记录操作历史，只维护一个位图标记哪些 512B 扇区已被写过，并在读时按需计算校验值。它绕过了 journal 的双重落盘开销，写路径接近裸设备，所以吞吐高、延迟低。
- 校验仅发生在读路径：若写入时出错（如掉电导致部分扇区写成功、部分失败），bitmap 不知道该扇区是否“完整可信”，下次读到它才会发现
integrity failure并返回EIO - bitmap 位图大小固定，由设备大小决定（例如 1TB 设备 ≈ 256KB bitmap），但所有位图页默认常驻内存，大容量设备（>10TB）可能显著增加内核内存占用
- 不支持
recovery机制：journal 模式崩溃后可回放日志恢复一致性；bitmap 模式只能靠上层文件系统（如 XFS 的 log）兜底，dm-integrity 层本身不保证崩溃一致性
怎么选模式？看你的 workload 和容错底线
别只盯着 benchmark 数字。journal 和 bitmap 的本质取舍是「写时强一致性」vs「读时懒校验 + 写性能」。
- 用 journal：数据库主数据盘、金融交易日志卷、任何要求“写即持久+可恢复”的场景；确认存储设备支持稳定
WRITE_CACHE和FLUSH（NVMe 要开nvme_core.default_ps_max_latency_us=0） - 用 bitmap：备份归档盘、媒体转码临时盘、CI 构建缓存卷；前提是上层已用
fsync()或日志文件系统兜住元数据一致性 - 混用不行：
dmsetup reload不能切换模式，必须dmsetup remove后重建，且原有数据全部丢失——没有在线迁移路径
实操中容易被忽略的初始化细节
模式选择只是第一步，真正影响性能的是初始化参数。比如 journal 模式下不调 journal_watermark，默认 75% 水位会频繁触发 checkpoint，把性能拖垮。
- journal 模式建议加参数：
journal_watermark=50（降低 checkpoint 频率）、journal_commit_time=5000（ms，避免太激进刷盘） - bitmap 模式务必确认
block_size匹配底层设备逻辑块大小（常见是512或4096），错配会导致Invalid argument错误，且错误信息里不提示具体哪项错 - 无论哪种模式，
integrity表的sector_size必须与底层设备一致，可通过blockdev --getss /dev/sdX查，否则挂载后首次 I/O 就卡死在bio_wait
实际部署时，最麻烦的不是选模式，而是验证它真正在起作用——echo 1 > /sys/block/dm-X/dm/integrity/metadata_mode 这类调试接口不可靠，唯一可信的是用 dd if=/dev/zero of=/dev/mapper/xxx bs=4k count=1 conv=fsync 配合 iostat 看 I/O 分布，再拔电源做故障注入测试。没做过掉电验证的 integrity 配置，等于没配。