数据库领域有个老生常谈但又特别难缠的问题撕裂写torn write。我在内核存储和数据库调优这条线上摸爬滚打这些年见过不少朋友在半夜三点被“页面一半新一半旧”的问题叫醒。2026 年的 LSFMMBPF 峰会上社区把目光明确对准了原子缓冲 I/O这让我觉得有必要把这几年围绕撕裂问题的实践经验、技术脉络和可落地的排查手段好好整理一番。这篇文章既适合内核开发者和存储工程师也适合那些正被数据库一致性折腾的 DBA 和 SRE希望能帮你在面对“撕裂之痛”时少走几步弯路。1. 数据库“撕裂”到底是怎么发生的1.1 从扇区到页撕裂的本质先把这个问题的物理本质说透。数据库的存储引擎以页page为单位管理数据MySQL 的 InnoDB 默认页大小是 16KBPostgreSQL 默认是 8KB。但底层存储设备以扇区sector为最小读写单位机械硬盘传统上是 512B现代 NVMe SSD 的逻辑块大小普遍是 4KB。问题就出在这层粒度错配上一次数据库页写入在块设备层会被拆成多个扇区请求。系统崩溃、突然断电、或者设备内部缓存被异常刷新时可能只完成了其中一部分扇区的落盘另外一部分还是旧数据。于是这个页就变成了“撕裂”状态——文件系统层面看这个页是写过的但页内的新旧数据混杂在一起checksum 出来全是错的数据页索引和内容对不上恢复起来非常痛苦。我用一个生活化的例子来解释相当于你写一篇论文正文替换了后半部分但前半部分还是草稿打印出来之后编辑看到的是上半段旧内容、下半段新内容整篇文章逻辑完全断裂。数据库里这种“断裂”发生在最底层的持久化环节影响会向上层层放大最终表现为莫名其妙的索引损坏、查询返回错误结果、崩溃后无法恢复。1.2 数据库自己怎么对抗撕裂数据库厂商早就意识到单靠块设备不可靠所以自己造了一套防护机制。最经典的是 InnoDB 的 doublewrite buffer在把脏页从内存刷到数据文件之前先把整页内容顺序写到系统表空间里一块连续的预留区域然后再写回数据文件。为什么有用因为 doublewrite 区域是顺序写的如果崩溃发生在写入过程中至少有一个完整且连续的页副本可以用来恢复避免了“半页”的数据陷阱。PostgreSQL 的思路不太一样它更依赖 WALWrite-Ahead Logging。任何数据页修改之前先把对应的日志记录落盘崩溃恢复时通过 replay 日志把页恢复到一致状态。同时 PG 也通过 full_page_write 机制在 checkpoint 后首次修改某个页时把整页内容记入 WAL专门对付部分写导致的页损坏。这些策略确实有效但代价也明显doublewrite 会带来额外的写放大每次刷脏页都得多写一份数据full_page_write 会显著增大 WAL 体积在写密集场景下带宽开销不容小觑。说白了这些“补丁式”方案都是为了应对底层缺少原子性而付出的额外成本。1.3 缓冲I/O为什么是重灾区很多人有个误区觉得只要用了 O_DIRECTDirect I/O绕开页缓存就不会有撕裂问题。实际上 O_DIRECT 只是减少了内核拷贝和页缓存占用的开销它并没有自动获得“原子写”语义。在 Linux 5.x 时代Direct I/O 的写入请求依然可能在块层被拆分异常掉电时照样可能部分完成。真正被忽视的重灾区是缓冲 I/O。数据库如果使用普通 write() 写入数据会先到页缓存由内核写回线程在后台刷盘。这里存在双重不确定性一方面内核可能把一次大写入拆成多次块请求另一方面写回时机完全不受数据库进程控制。换句话说应用层以为 write() 已经返回成功了实际上数据还没落到盘上就算落盘了也可能落在“半路”状态。所以“原子缓冲 I/O”要解决的核心矛盾就是既想享受页缓存带来的性能和便利又想在故障场景下避免页被撕裂。这需要内核在页缓存、块层、文件系统之间形成一套统一的原子语义把“写一个页就是写一个原子单元”这件事从底层坐实。2. LSFMMBPF 2026为什么这个话题值得追2.1 内核存储会议的议题脉络LSFMMBPF 是 Linux 存储、文件系统、内存管理和 BPF 方向的年度技术会议内核维护者、文件系统作者、存储厂商和云厂商的专家都会参与。会议不搞花哨的 keynote大部分时间就是对着一块白板讨论补丁、讨论设计草案、当场拍板下一步方向。这几年我持续关注会议 release notes发现数据库相关场景一直在推动内核存储接口演进。2026 年的议题把“原子缓冲 I/O”提到核心位置我理解是两条线索汇合的结果一条是数据库社区反复提交的“我们需要原生原子写支持”的诉求另一条是近几个内核版本里 RWF_ATOMIC 这类 O_DIRECT 原子写能力已经逐渐成熟、文件系统支持也开始落地。既然 Direct I/O 这条路走通了下一步自然要把原子语义延伸到缓冲 I/O 域把“最后一公里”补上。2.2 原子缓冲I/O要解决什么如果只看表面原子缓冲 I/O 的目标很直接让通过页缓存写入的数据页在崩溃后不会出现半新半旧的状态。但实现层面远没有这么简单页缓存机制本身就包含很多层级。首先是页缓存与块设备的映射问题一个文件页可能对应多个磁盘块写回时如果按块粒度下发请求就无法保证整页原子落盘。理想设计是文件系统层面支持“原子写单元”把一个页或用户指定的对齐区域一次性提交到底层设备避免部分扇区写入。其次是写回顺序问题页缓存有大量脏页后台写回线程会按一定策略批量刷盘既要保证顺序又不能让大量小请求破坏原子性。G 接着是文件系统日志的配合像 ext4 的 dataordered 模式已经保证先写数据再提交元数据但“数据本身是否原子落盘”并不是文件系统能单独承诺的。真正落地需要块层和文件系统协同文件系统告诉块层“这是一次原子写请求”块层在合适的设备能力下把请求合并为一次不可分割的物理提交。还有一个关键设计点原子写要求能够fail fast。如果设备或文件系统不支持原子写应该通过 statx 或明确错误码告诉应用而不是静默退化为普通写。否则数据库以为自己拿到了原子保证实际又没有这比没有更危险。2.3 BPF在“最后一公里”里的角色BPF 在这次讨论里被频繁提及不是因为它能直接实现原子写而是它提供了一个关键的配套能力可观测性。撕裂问题的追查一向困难因为它是故障瞬间才暴露的普通监控根本看不到。借助 BPF我们可以动态追踪块层请求的拆分情况、页缓存回写的下发大小、文件系统日志提交的时序甚至在模拟故障时精确记录哪些请求是“成功返回但只完成了一半”。我在实际工作中用 bpftrace 挂载 block 层和 writeback 相关探针把崩溃前后的 I/O 路径完整还原出来定位效率比暴力加日志高了一个数量级。此外BPF 在 I/O 路径上的延展性也很好。可以通过 BPF 程序在写回路径上做策略插桩比如追踪指定文件的原子写请求是否符合预期或者监控是否存在静默退化为非原子写的情况。这些能力让 LSFMMBPF 会议把“原子缓冲 I/O”和 BPF 放在同一个议题里本质是希望解决“怎么验证新机制真的生效”的问题——光有机制没有可观测手段生产环境根本不敢上。3. 实操在现有内核上把撕裂问题“抓出来”3.1 环境准备构造一个会出问题的盘理论讲再多不如亲手复现一次撕裂。我在测试环境里最常用的方式是通过 device-mapper 构造一个带故障注入的块设备。思路很简单让上层认为自己写成功了但实际只完成部分扇区落盘。先准备好一块测试盘可以用空闲 SSD 或内存盘然后在它之上叠加 dm-dust。dm-dust 是一个专门模拟“部分写失败”的 target可以精确控制某个扇区在写入时直接丢弃数据。配置方式非常直接# 创建基于 /dev/sdb 的 dm-dust 设备 echo 0 $(blockdev --getsize /dev/sdb) dust /dev/sdb 0 | \ dmsetup create dust-test # 启用某个扇区的“失败写入”特性 dmsetup message dust-test 0 add_dust 2048这样当块设备向第 2048 号扇区发起写请求时dm-dust 会让这次写入“丢失”而上层驱动的 write() 依然可能返回成功。如果把数据库的数据文件放在这个 dm-dust 设备之上再配合 kill -9 模拟崩溃撕裂状态就自然出现了。除了 dm-dust还可以用 dt 工具或者直接修改块设备的 max_sectors_kb 来强制拆分请求。比如把设备的 max_sectors_kb 设成 4即 4KB扇区大小设为 512B那么一个 16KB 的数据库页必然会被拆成多个 4KB 请求故障时更容易观察到部分写。提示不要在生产环境的真实数据盘上做这类实验。dm-dust 之类的故障注入设备只适合在隔离的测试环境中使用否则一个参数配错整块盘的数据都会遭殃。3.2 用BPF追踪部分写路径环境准备好之后下一步是让撕裂问题“可视化”。Linux 块设备层的 tracepoint 是我们的第一手数据来源其中 block_rq_issue 可以在请求下发时打印出请求的起始扇区和大小。下面是一段非常实用的 bpftrace 脚本可以实时监控某个 dm 设备上的所有块请求#!/usr/bin/env bpftrace tracepoint:block:block_rq_issue { // 只关注我们指定的设备 if (str(args-dev_name) dm-0) { printf(issue: dev%s sector%lu nr_sectors%u rw%d\n, args-dev_name, args-sector, args-nr_sectors, args-rwbs); } } tracepoint:block:block_rq_complete { if (str(args-dev_name) dm-0) { printf(done: dev%s sector%lu nr_sectors%u err%d\n, args-dev_name, args-sector, args-nr_sectors, args-error); } }把脚本跑起来然后对测试盘上的数据库执行写入你会看到类似下面的输出issue: devdm-0 sector2048 nr_sectors8 rwW done: devdm-0 sector2048 nr_sectors8 err0 issue: devdm-0 sector2056 nr_sectors8 rwW done: devdm-0 sector2056 nr_sectors8 err0注意看请求的 nr_sectors 字段如果数据库页是 16KB、扇区是 512B那么一个完整的页写应该看到 32 个扇区的连续请求。如果请求被拆成多段或者某段 sector 没有对应的完成事件这就是撕裂写正在发生的信号。在追踪页缓存回写路径时还可以挂载 writeback 相关的 tracepoint观察回写线程是否把大页拆散成碎片请求下发。这通常比盯着数据库日志更直接因为问题在诞生现场就被记录下来了。3.3 模拟数据库崩溃并观察恢复结果拿到 I/O 轨迹后就模拟一次真实的崩溃恢复流程。用 MySQL 作为例子在测试环境里执行以下步骤在 dm-dust 设备上初始化 MySQL 数据目录建一张表并灌入一定量的数据。开启一个大事务持续 UPDATE 一张表让磁盘写入不断发生。在写入压力最大时用kill -9杀掉 mysqld 进程模拟断电崩溃。重启 mysqld打开innodb_force_recovery0观察错误日志和SHOW ENGINE INNODB STATUS。如果 dm-dust 配置在数据文件的关键扇区上你会看到 InnoDB 在启动时报告“Database page corruption detected”或者“Page is being overwritten”之类的错误。接下来对比一种配置启用 innodb_doublewrite重复同样流程大概率能够正常恢复因为 doublewrite buffer 提供了一个完整页副本用于修复。这个实验的价值在于直观展示“有原子语义”和“没有原子语义”的差异同时也能帮你验证一个结论数据库自身防护机制虽然有用但本质是在兜底是在为块设备的不确定性买单。如果我们把块设备层变成原子单元数据库完全可以少做很多无谓的重复写。4. 原子缓冲I/O落地后数据库能省下什么4.1 从doublewrite到原生原子写假设未来内核完整支持原子缓冲 I/O数据库社区最先能拿掉的就是 doublewrite buffer 的一部分负载。InnoDB 使用 doublewrite 的场景分两类一类是刷脏页时防半页写另一类是 redo log 应用时的页修复。如果底层文件系统已经保证“一个页的写是原子的”那 doublewrite 作为一个“整页备份池”的意义就会大大下降。当然doublewrite 还有另一个作用压缩页写入compressed page和跨页操作的保护这些依然需要更上层的策略来兜底。所以我的判断是短期内 doublewrite 不会完全消失但它的角色会从“每次写都必经的额外通道”退化为“只对特殊场景生效的保险丝”不再成为常规写路径的固定成本。PostgreSQL 也类似。如果原子缓冲 I/O 成熟full_page_write 的需求会减少WAL 体积会有明显下降。尤其在高并发更新场景下WAL 里的整页镜像占比相当高去掉这部分日志写入和归档的带宽压力都能显著缓解。4.2 性能收益的粗略估算写放大是衡量这类优化最直观的指标。拿 MySQL 双写机制来算一笔账假设数据页大小为 16KB每次刷脏页需额外写 16KB 到 doublewrite buffer也就是说写放大至少增加 100%。如果开启 doublewrite每次崩溃恢复时还有额外的分组拷贝开销在高性能 NVMe 盘上这部分时间同样不可忽略。换成原生原子写之后这条额外路径直接消失Percona 社区早期在类似原型上的测试结果也比较乐观部分纯写场景能看到 10%-20% 的吞吐提升。要注意的是这个提升不一定在所有负载下都明显尤其是读取多、写入少的场景doublewrite 本身影响就不大。另一个受益点是延迟稳定性。doublewrite 的批量刷盘会导致周期性 IO 尖刺尤其在 buffer pool 达到刷盘水位时延迟曲线会突然拔高。去掉双写后写路径变得更加平顺这对那些对 P99 延迟敏感的业务来说是实打实的改善。空间层面也有收益doublewrite buffer 默认占系统表空间的一部分在超大实例上也是不小的一笔存储开支更关键的是WAL/redo 里整页镜像减少之后日志归档和备库同步的网络传输量也会降下来这在跨机房部署的场景里效果更直观。4.3 落地部署时的兼容性清单看到这里可能有人想立刻在自己的生产库上开启原子写我劝你先冷静。根据目前内核社区的推进情况这项能力落地需要满足一串前置条件内核版本支持至少需要有 RWF_ATOMIC 相关支持的内核版本并且文件系统驱动实现了原子写回调。文件系统支持目前 XFS 是推进最快的文件系统ext4 和 btrfs 也在跟进。不要默认“一个内核版本支持就等于所有文件系统都支持”。块设备能力底层设备需要能够保证原子写单元不小于数据库页大小。NVMe 协议里的原子写能力、逻辑块大小、Write Atomicity 参数都需要提前确认。应用调用方式数据库是否已经把写入请求切换成新的原子写标志位这取决于数据库版本和内核接口的兼容层。部署判断先确认 statx 返回的 stx_atomic_write_unit_min 和 stx_atomic_write_unit_max 是否覆盖你的页大小。如果最大值小于页大小那么即使开了原子写也保证不了整页原子性这时候老老实实继续用数据库自带保护机制更安全。5. 常见问题与排查技巧实录5.1 问题速查表这些年遇到过的典型问题整理了一张速查表按现象、原因、解决方向列出现象常见原因建议排查方向崩溃恢复后报 Data page corruption页写入时设备只完成了部分扇区落盘检查日志中的 LSN 不匹配用 dm-dust 复现确认是否关闭了 doublewrite内核返回 EINVAL 或 ENOTSUP文件系统或设备不支持原子写查看 statx 输出、/sys/block/xxx/queue 下的原子写属性换用 XFS 试开启原子写后性能不升反降原子写请求过度串行化或对齐开销过大对比不同 I/O 深度检查请求是否被拆散确认调度器和 NVMe 队列配置写入顺序改变导致恢复日志错乱缓冲 I/O 的写回顺序不可控需要文件系统层配合检查 dataordered 或类似保证是否生效使用了 BPF 脚本却没有输出tracepoint 事件挂在别的设备或路径上用ls /sys/kernel/debug/tracing/events/block/确认 tracepoint 名称和事件可用性5.2 排查心得与避坑经验最后分享几条实操中积累的经验。第一不要迷信闪存类设备。很多人觉得 SSD 没有机械结构掉电不会半写。实际上现代 SSD 内部有 DRAM 缓存和 FTL 重映射异常掉电时如果固件来不及把映射刷完照样可能出现部分写。尤其是消费级 SSD 的 write cache 策略、PLPPower Loss Protection方案差异极大同一批盘在不同固件版本下表现都不同。第二BPF tracepoint 的输出不只看 error 字段。很多块设备错误返回时 error0但数据其实已经丢了比如 dm-dust 故意吞掉写入。判断是否发生部分写关键是对比 issue 和 complete 的扇区范围是否一致以及设备最后一次写后的 metadata 状态。第三做故障注入测试时最好在数据库层也加一层校验。比如开启 InnoDB 的 innodb_checksum_algorithm 并选择严格模式这样崩溃后扫描能看到具体是哪一页的 checksum 不匹配把问题从“有一页坏了”缩小到“哪个页、哪个 LSN 范围”排查效率会高很多。第四适配原子写时应用程序的对齐要求比 O_DIRECT 更严格。原子写一般要求文件偏移、长度、缓冲区地址都满足原子写单元的对齐条件随便写一个 struct 数组起点不对内核还是会退化为普通写。要在应用里显式做内存对齐比如用 posix_memalign 分配 I/O buffer。原子缓冲 I/O 这项能力还在快速演进中内核社区和数据库社区的讨论密度很高但接口设计、文件系统支持度和设备颗粒度这些关键细节已经逐渐明朗。我个人在实际环境里最深的体会是撕裂问题从来不是“加个 checksum 就完事”的软件层面的状态一致性问题只有把底层 I/O 的原子语义补齐数据库这套复杂系统才能彻底卸下身上的历史包袱。希望这篇梳理能帮你在下次遇到“坏页”报警时知道该看哪些请求、该配哪些参数、该往哪个方向追。
