1. 当脚本说写完了硬盘却说我什么都没收到做过存储测试、驱动开发或者嵌入式块设备调试的人大概率都遇到过这种让人头皮发麻的场景脚本跑完dd或者fio返回码干干净净日志里一行PASS打得理直气壮结果你转头去读那块 LBA读回来的全是0x00。脚本说写成功了OS 读出来是空的两边各执一词到底谁在撒谎这个问题在设备老化测试、全自动执行脚本、块设备驱动验证这些场景里出现频率极高。尤其是做老化测试的时候脚本一跑就是几十个小时中间只要有一次假 PASS后面所有的测试数据全部作废甚至可能把一块本来有问题的盘当成好盘放行。更麻烦的是这种问题往往不是必现的你重跑一遍它就好了再跑一遍又复现了典型的间歇性故障排查起来极其折磨人。我自己在块设备测试这条线上踩过不少次这个坑从最早的 SATA 盘到后来的 NVMe、UFS再到各种嵌入式存储介质几乎每一类设备都遇到过脚本 PASS、OS 读全零的情况。这里面牵扯到的知识点其实非常密集缓存层级、LBA 寻址、off-by-one 边界、写缓存刷新语义、OS 页缓存与设备缓存的交互任何一个环节出问题都会表现为写成功但读不到。这篇文章不打算泛泛而谈而是把脚本说 PASS、OS 读全零这个现象拆开从缓存、LBA、off-by-one 三个最核心的方向入手把每一层可能撒谎的地方都揪出来。不管你是写测试脚本的、调驱动的还是做存储固件的只要你的工作里涉及写进去再读出来验证这个动作这篇内容应该都能帮你少走一些弯路。2. 缓存的三层结构谁在替谁背锅要搞清楚写成功但读全零第一步必须把数据从脚本到介质之间经过的缓存层级理清楚。很多人排查的时候只盯着设备缓存结果查了半天发现是 OS 页缓存的问题方向一开始就错了。2.1 从 write() 返回到数据真正落盘中间隔了多少层一个典型的写操作路径是这样的应用层调用write()数据先进入OS 页缓存Page Cache这时候write()就返回了脚本拿到返回值认为写成功。但数据此时可能还在内存里根本没到设备。接着内核的块层会把脏页组织成 bio经过IO 调度器合并排序再下发给驱动。驱动把请求转成设备命令写入设备的易失性写缓存Volatile Write Cache设备返回命令完成。到这一步数据可能还在设备的 DRAM 里没有真正写进 NAND 或者磁介质。所以从脚本的视角看写成功这个信号最早在页缓存那一层就已经返回了。后面每一层都可能出问题而脚本完全感知不到。这就是为什么脚本说 PASS这件事本身的可信度取决于你在脚本里到底做了什么级别的同步操作。2.2 页缓存、设备写缓存、介质缓存各自的撒谎方式这三层缓存各有各的脾气撒谎的方式也不一样。页缓存最典型的撒谎是你写完立刻去读读到的其实是页缓存里的数据根本没走设备。这种情况下读出来是对的但设备上可能是空的。反过来如果你用了O_DIRECT绕过页缓存写完立刻读读到的就是设备真实返回的数据这时候如果设备写缓存还没刷读出来就可能是旧数据或者全零。设备写缓存的问题在于设备收到写命令后数据进了它的 DRAM 就返回完成但掉电或者复位之后数据就没了。老化测试里如果中途有复位操作之前写成功的数据可能全部丢失。更隐蔽的是有些设备在写缓存满或者特定条件下会静默丢弃数据命令照样返回成功。介质层的问题更底层比如 NAND 的编程失败、坏块替换、FTL 映射表更新延迟这些都会导致数据实际没写进去但设备返回的是成功。这种情况通常需要读回来做校验才能发现。2.3 为什么写完立刻读这个动作本身就不可靠很多人验证写操作的方式是写完立刻读回来比对这个做法在带缓存的系统上基本没有意义。因为写完立刻读读的很可能是同一份缓存数据你验证的是缓存不是介质。正确的做法是要么在写之后执行一次flush/fsync强制刷盘要么用O_DIRECT加设备级 flush 命令确保数据真正落到介质上再读。但即便这样还要注意读的时候也要绕过缓存否则读回来的还是缓存里的旧数据。这里有个经验在老化测试脚本里写验证一定要成对出现——写的时候带 flush读的时候带 invalidate。只做一半验证结果就是自欺欺人。3. LBA 寻址你以为写到了 A其实写到了 B缓存问题解决之后下一个高频嫌疑对象就是 LBA。LBALogical Block Address是块设备寻址的基础脚本里算错一个扇区数据就写到别的地方去了读的时候自然读不到。3.1 LBA 单位换算里最容易被忽略的坑LBA 的单位是逻辑块不是字节。一个逻辑块通常是 512 字节或者 4096 字节具体取决于设备。脚本里如果混用了字节偏移和 LBA就会出现写到了错误位置的问题。举个最常见的例子你想写偏移 1MB 处的一个块设备逻辑块大小是 512 字节。正确的 LBA 是1MB / 512 2048。但如果你直接拿1MB当 LBA 传给设备实际写的位置就是1MB * 512 512MB处。读的时候如果按正确 LBA 读读到的当然是全零。这种错误在脚本里特别隐蔽因为dd的seek参数、fio的offset参数、驱动的 LBA 字段三者的单位可能都不一样。dd的seek默认按块大小算fio的offset按字节算驱动接口按 LBA 算。混用一次数据就飞了。3.2 分区偏移叠加导致的写飞比单位换算更隐蔽的是分区偏移。假设你的设备上有一个分区起始 LBA 是 2048。你在分区内偏移 0 处写数据实际写到设备的 LBA 2048。但如果你在脚本里直接操作整盘设备又按分区内的偏移去算 LBA就会写到设备的 LBA 0 处而分区内的 LBA 0 对应的是设备的 LBA 2048。读的时候从分区读读的是设备 LBA 2048当然读不到你写在 LBA 0 的数据。这个问题在多分区、多命名空间的设备上尤其常见。NVMe 的 namespace、UFS 的 LU、eMMC 的 partition每一层都有自己的偏移。脚本里如果没把偏移叠加算清楚写和读就会落在不同的物理位置上。3.3 用一张表把脚本偏移和设备 LBA对齐排查 LBA 问题最有效的方法是做一张映射表把脚本里的每一个偏移逐层换算到设备 LBA然后核对。层级单位换算关系常见错误脚本字节偏移字节基准直接当 LBA 用逻辑块偏移逻辑块字节 / 块大小块大小取错512 vs 4096分区内 LBA逻辑块逻辑块偏移忘记叠加分区起始设备 LBA逻辑块分区内 LBA 分区起始多命名空间偏移漏算这张表建议在排查的时候直接手算一遍把脚本里写的偏移和读的偏移都换算到设备 LBA对比一下是不是同一个位置。十次里有八次问题就出在这张表的某一行上。提示逻辑块大小不要凭记忆一定要用blockdev --getss或者读设备的 identify 数据确认。不同设备、不同命名空间块大小可能不一样。4. off-by-one差一个块结果差一个世界LBA 算对了缓存也刷了结果还是读全零这时候就要怀疑 off-by-one 了。off-by-one 是编程里最经典的错误类型在块设备场景下它的破坏力被放大得特别明显因为差一个块就是差几百字节到几千字节的数据。4.1 循环边界写错最后一个块永远写不进去最常见的 off-by-one 出现在写循环里。比如你要写 100 个块循环写成for i in range(99)那只写了 99 个块第 100 个块没写。读的时候如果读 100 个块最后一个块读出来就是全零或者旧数据。这种错误在脚本里特别容易发生因为脚本语言的范围表达方式各不相同。Python 的range(100)是 0 到 99Shell 的seq 1 100是 1 到 100C 的for(i0;i100;i)是 0 到 99。混用的时候边界差一个太正常了。更麻烦的是这种错误往往不会导致脚本报错因为写 99 个块和写 100 个块命令都成功返回了。只有读回来比对的时候才会发现最后一个块不对。4.2 长度字段和起始地址的差一组合比循环边界更隐蔽的是长度字段和起始地址的组合错误。比如你从 LBA 100 开始写写 10 个块正确的范围是 LBA 100 到 109。但如果长度字段写成了 11就会写到 LBA 110多写一个块。如果长度写成了 9就少写一个块LBA 109 没写到。读的时候如果按 LBA 100 到 109 读长度写错的那个块就会读不到。这种错误在驱动层和固件层特别常见因为长度字段的定义有时候是块数有时候是最后一个块的地址两种约定混用就会差一。4.3 用边界值测试把 off-by-one 逼出来排查 off-by-one 最有效的方法是做边界值测试。不要只测中间区域要专门测起始块、结束块、起始块减一、结束块加一这几个位置。具体做法是在 LBA 0、LBA 1、LBA n-1、LBA n 这几个位置分别写入不同的模式数据然后读回来比对。如果 LBA 0 写不进去说明起始地址算错了如果 LBA n-1 写不进去说明长度少了一个如果 LBA n 写进去了但你不该写说明长度多了一个。这个测试建议做成脚本里的固定环节每次跑老化测试之前先跑一遍边界值测试确认 LBA 计算逻辑没问题再开始长时间测试。这样能把 off-by-one 问题在早期就暴露出来不用等到跑了几十个小时才发现。5. 一次完整的排查链路从现象到根因前面把缓存、LBA、off-by-one 三个方向都拆开了但实际排查的时候这三个方向往往是交织在一起的。下面用一个真实的排查案例把完整的链路走一遍。5.1 现象复现脚本 PASS读回来全零现象是这样的老化测试脚本对设备做顺序写每写 1MB 就读回来校验一次。跑了大概 3 个小时之后某一次校验失败读回来的 1MB 全是零。脚本记录了这个失败但继续往下跑后面的校验又正常了。重跑同样的脚本有时候能复现有时候不能。这种间歇性复现是最难查的因为它不是必现你没法稳定地抓现场。第一步要做的不是急着改代码而是加日志把每次写和读的 LBA、长度、数据模式都记下来尤其是失败那一次的完整参数。5.2 分层验证先排除缓存再锁定 LBA加了日志之后发现失败的那一次写的 LBA 和读的 LBA 是一样的长度也一样。这就排除了 LBA 算错的可能。接下来验证缓存。在写之后加fsync在读之前加posix_fadvise丢弃页缓存再跑。结果还是偶发失败。这说明问题不在页缓存可能在设备写缓存或者介质层。接着在写之后加设备级 flush 命令比如 NVMe 的 FlushSCSI 的 SYNCHRONIZE CACHE确保数据落到介质。再跑失败率明显下降但没有完全消失。这说明设备写缓存是其中一个原因但还有别的问题。5.3 根因定位写缓存未刷 边界块未写继续深挖把失败那一次的 LBA 范围单独拿出来分析发现失败的块总是落在某一段 LBA 的边界上。进一步检查发现脚本在写这一段的时候长度字段比预期少了一个块导致最后一个块没写。而读的时候是按完整长度读的所以最后一个块读出来是全零。同时设备写缓存未刷导致在特定条件下前一个块的写入被延迟读的时候读到了旧数据。两个问题叠加就表现为偶发的读全零。根因是两个off-by-one 导致边界块未写加上写缓存未刷导致数据延迟。单独修任何一个问题都只能缓解不能根除。5.4 修复与回归怎么确认真的修好了修复方案是修正长度字段的计算确保边界块被写入同时在每次写之后加设备级 flush确保数据落介质。修完之后怎么确认真的修好了不能只跑一遍通过就算完。要做的是把失败那一次的 LBA 范围单独拿出来做定向压力测试反复写读这个范围几千次确认不再复现。然后再跑完整的长时间老化测试至少跑够之前失败时间的 3 倍确认稳定。这里有个经验间歇性问题修复之后回归测试的时间一定要足够长至少要覆盖之前失败的时间窗口。跑 10 分钟通过不代表修好了可能只是还没到触发条件。6. 写验证脚本时我踩过的那些坑排查完这个案例之后我回头把写验证脚本的常见坑整理了一遍。这些坑不一定都会导致读全零但都会让验证结果不可信。6.1 只校验返回值不校验数据最常见的坑就是脚本只看write()的返回值返回成功就认为写成功了。但前面说过返回值成功只代表数据进了某一层缓存不代表落盘。正确的做法是写完必须读回来比对而且读的时候要绕过缓存。比对的时候还要注意不要只比对长度要比对内容。有些脚本只检查读回来的字节数对不对不检查内容这样即使读回来全是零只要长度对脚本也认为 PASS。这种验证等于没验证。6.2 用随机数据但没记录种子用随机数据做验证是对的因为固定模式的数据可能被设备压缩或者特殊处理掩盖真实问题。但用随机数据一定要记录种子否则失败之后没法复现。我见过有脚本用random生成数据失败之后想复现结果种子没记重新生成的数据和之前不一样根本没法定位。正确的做法是把种子写进日志失败之后用同样的种子重新生成数据才能复现。6.3 忽略设备返回的 sense data设备返回错误的时候除了状态码还会带 sense data里面有具体的错误原因。很多脚本只看状态码状态码是成功就往下走完全不看 sense data。但有些设备会在 sense data 里报告写缓存未刷介质错误之类的警告这些警告如果不处理后面就可能变成读全零。建议在脚本里把 sense data 也解析出来至少记录到日志里。排查的时候这些信息非常有用。6.4 长时间测试不做阶段性校验老化测试跑几十个小时如果只在最后做一次校验中间出了问题根本不知道是什么时候出的。正确的做法是分段校验每跑一段时间就校验一次把失败的时间点和 LBA 范围都记下来。分段校验还有一个好处就是能把问题和特定的操作序列关联起来。比如失败总是发生在某次复位之后或者某次 flush 之后这样排查方向就明确多了。7. 把谁在撒谎变成谁没同步回到最开始的问题脚本说 PASS、OS 读全零到底是谁在撒谎排查到最后你会发现大多数情况下没有人撒谎只是同步语义没对齐。脚本认为写成功是因为它只看到了write()的返回值OS 认为读全零是因为它读的时候缓存没失效或者读的 LBA 和写的 LBA 根本不是一个位置。每一层都按自己的语义在正常工作但层与层之间的同步没做对就表现为互相矛盾。所以排查这类问题的核心思路不是去怀疑某一层撒谎而是去检查每一层的同步点写完之后有没有 flush读之前有没有 invalidateLBA 换算有没有对齐长度字段有没有差一。把这几个同步点都对齐了脚本 PASS、OS 读全零这种现象基本就消失了。我在实际项目里总结下来写验证脚本的时候只要坚持三个原则就能避开绝大多数这类问题写后必刷、读前必失效、边界必测。这三个原则看起来简单但真正在长时间老化测试里坚持执行能省掉大量排查时间。尤其是边界必测这一条很多 off-by-one 问题就是在边界上暴露的中间区域怎么测都正常一到边界就出问题。最后再分享一个小技巧如果你的测试环境允许可以在写验证脚本里加一个影子校验环节就是在写完之后用另一种完全独立的路径比如换一个工具、换一个接口再读一次两次读的结果比对。如果两条路径读出来的结果不一致说明中间某一层有问题。这个方法能帮你快速定位问题是出在缓存层、驱动层还是设备层比单路径排查效率高很多。