脚本PASS但OS读全零？AHCI/PIO/MBR分层排查实战

1. 问题现场还原：一个让老运维都挠头的"罗生门"

1.1 现象描述：脚本说 PASS，系统读出来全是零

先把这个场景原原本本摆出来。你写了一个设备老化测试的全自动执行脚本，跑完一轮之后脚本自己汇报"PASS"，日志里各项指标看着也正常。但当你手动去读那块盘的数据时，dd出来全是0x00，hexdump一看整片空白，smartctl可能还告诉你"健康状态良好"。这时候你脑子里第一个念头就是：到底谁在撒谎？

这个现象在存储设备老化测试、批量产线检测、嵌入式板卡验收里非常典型。脚本说 PASS，是因为它只检查了"命令有没有报错"；OS 读全零，是因为它读的是块设备层返回的数据，而块设备层可能压根没真正碰到盘。中间隔着的 AHCI、PIO、MBR 这些环节，任何一环出问题，都会造成"上层以为成功、底层其实没动"的假象。

我先把结论方向给出来，免得你看到后面才恍然大悟：绝大多数情况下，撒谎的不是脚本，也不是 OS，而是"中间层把错误吞掉了"。脚本拿到的是exit code 0，OS 拿到的是缓存或未初始化缓冲区，两边都没错，错的是它们之间的信任链断了。

1.2 为什么这个问题值得单独写一篇

很多人遇到这个现象，第一反应是"盘坏了"，换盘；换完还这样，就怀疑"脚本写错了"，重写；重写完依旧，就开始怀疑人生。实际上这是一个分层排查的经典案例，涉及从应用层脚本、OS 块设备层、AHCI 控制器、PIO/IDE 兼容模式，一直到 MBR 分区表这一整条链路。

热词里出现的AHCI、PIO、MBR不是随便凑的，它们恰好对应了这条链路上最容易出问题的三个位置：

• AHCI：现代 SATA 控制器的工作模式，负责把 OS 的读写请求翻译成 SATA 命令。
• PIO：老式的 Programmed I/O 模式，CPU 亲自搬数据，速度慢但兼容性好，很多老化测试脚本为了"稳"会强制走 PIO。
• MBR：主引导记录，分区表的载体，如果 MBR 区域被写坏或压根没写，OS 读分区就会读到全零。

把这三个点串起来，你就能理解为什么"脚本 PASS + OS 全零"会同时出现。下面我按"设计思路 → 核心细节 → 实操复现 → 排查技巧"的顺序，把这条链路彻底拆开讲。

2. 整体设计思路：为什么会出现"双层真相"

2.1 脚本的"PASS"到底在判断什么

先看脚本这一层。一个典型的老化测试脚本，逻辑大概是这样：

#!/bin/bash DEV=/dev/sdb for i in $(seq 1 100); do dd if=/dev/zero of=$DEV bs=1M count=100 conv=fsync 2>/dev/null if [ $? -ne 0 ]; then echo "FAIL at round $i" exit 1 fi done echo "PASS"

这段脚本的PASS只代表一件事：dd命令的返回码是 0。而dd的返回码是 0，只代表"write 系统调用没有返回错误"。它不保证数据真的落到了盘上，也不保证盘真的接受了这些数据。

这就是第一个"撒谎点"：脚本把"系统调用没报错"等同于"设备工作正常"。在正常环境下这两者基本等价，但在老化测试、异常掉电、控制器降速、PIO 超时被吞等场景下，它们会分道扬镳。

2.2 OS 读全零的三种可能来源

再看 OS 这一层。你用dd if=/dev/sdb of=dump.bin bs=1M count=100读出来全零，可能是下面三种情况之一：

第一种最隐蔽。Linux 的块设备读写默认走 page cache，你写 100MB 零，内核可能只把它放进缓存就返回成功，真正的落盘是异步的。如果你没fsync、没O_DIRECT、没sync，读回来当然还是零——因为盘上从来没被写过。

第二种是硬件层面的"沉默失败"。某些老化的 SATA 盘或控制器，在 PIO 模式下遇到超时会静默丢弃命令，不报错也不写入。脚本看到的是成功，盘上什么都没有。

第三种是 MBR 层面的问题。如果测试脚本第一步是"清空 MBR"，而后续的写入又因为某种原因没生效，那么 OS 读分区表时读到全零，就会认为"这块盘没有分区"，进而读出全零。

2.3 为什么 AHCI 和 PIO 的切换是关键变量

这里必须单独讲 AHCI 和 PIO 的区别，因为它是"脚本 PASS、OS 全零"最常见的物理层诱因。

AHCI 模式下，控制器支持 NCQ（原生命令队列）、热插拔、错误详细上报。命令失败会通过task file返回具体错误码，OS 能感知到。

PIO 模式下，CPU 通过端口寄存器一个字节一个字节地搬数据。这种模式没有队列、没有详细错误上报，超时了往往就是一个"设备无响应"，然后控制器可能直接放弃，OS 收到的是一个模糊的失败或者干脆被上层忽略。

很多老化测试脚本为了"兼容老设备"，会在 BIOS 里把 SATA 模式从 AHCI 改成 IDE/PIO。改完之后：

• 脚本依旧能跑，因为dd不关心底层模式；
• 但写入可能因为 PIO 超时被丢弃；
• OS 读回来就是全零。

热词里win11改ahci模式无法启动也是同一个根源的另一面：模式切换会导致驱动栈不匹配，系统找不到盘。这说明 AHCI/PIO 这个开关的影响面远比想象中大。

3. 核心细节解析：从脚本到盘片的完整链路

3.1 数据写入的五个阶段

要搞清楚谁在撒谎，必须知道一次dd写入到底经过了哪些阶段：

1. 应用层：dd调用write()，数据进入内核。
2. VFS/块设备层：数据被放进 page cache，标记为 dirty。
3. IO 调度层：内核决定何时把 dirty page 下发给块设备驱动。
4. 驱动层（AHCI/PIO）：驱动把请求翻译成 SATA 命令，写入控制器寄存器。
5. 物理层：盘片/闪存真正接收并存储数据。

脚本的PASS只覆盖了第 1 到第 2 阶段。第 3 到第 5 阶段如果出问题，脚本完全无感。这就是"撒谎"的结构性原因。

3.2 fsync、O_DIRECT、sync 三者的区别

要堵住这个漏洞，必须让脚本"等到数据真正落盘"。三种手段各有适用场景：

• fsync(fd)：把该文件描述符对应的 dirty page 刷到设备，并等待设备确认。适合文件级操作。
• O_DIRECT：绕过 page cache，直接读写设备。适合块设备测试，但要求缓冲区对齐。
• sync：全局刷所有 dirty page。粗暴但有效，适合测试收尾。

在老化测试脚本里，我通常建议用O_DIRECT+fsync组合：

dd if=/dev/zero of=$DEV bs=1M count=100 oflag=direct,fsync

oflag=direct让写入绕过缓存，fsync确保落盘。这样脚本的PASS才真正代表"盘接受了数据"。

3.3 MBR 区域为什么容易被误判

MBR 位于设备的第 0 扇区（512 字节）。它的结构是：

如果测试脚本先dd if=/dev/zero of=$DEV bs=512 count=1清空 MBR，然后写入数据，但写入没生效，那么 OS 读第 0 扇区就是全零。此时fdisk -l会告诉你"没有分区表"，partprobe会失败，任何基于分区的读取都会返回零。

更隐蔽的是：有些脚本会先写 MBR 再写数据区，如果 MBR 写成功但数据区写失败，你会看到"分区存在但内容全零"。这时候smartctl依然报健康，因为盘本身没坏，只是数据没写进去。

3.4 PIO 模式下的超时吞错机制

PIO 模式的数据传输依赖 CPU 轮询状态寄存器。当设备响应慢时，驱动会等待一个超时周期。如果超时，理论上应该返回-EIO。但实际中，某些老控制器或虚拟化环境会把超时当作"完成"处理，直接返回成功。

这就造成了最恶劣的情况：脚本 PASS，OS 读全零，盘上确实什么都没有，但没有任何一层报错。

识别这种情况的方法是看内核日志：

dmesg | grep -i -E "ata|ahci|pio|timeout|error"

如果看到ata1.00: exception Emask 0x0或ata1: lost interrupt之类的信息，基本可以确认是 PIO 超时被吞。

4. 实操复现：一步步造出"脚本 PASS、OS 全零"

4.1 环境准备与设备选择

要复现这个现象，最好用一块可以随便折腾的盘，或者用 loop 设备模拟。我用的是：

• 一块老旧的 2.5 寸 SATA 盘（容量 160GB，通电时间超过 5 万小时）
• 一台支持 AHCI/IDE 切换的老主板
• Linux 环境（内核 5.x 以上）

先用lsblk确认设备名，假设是/dev/sdb。注意：以下操作会清空设备数据，务必确认设备名正确。

4.2 复现步骤一：制造未落盘的写入

第一步，故意不加fsync，让写入停留在缓存：

# 清空设备前 100MB dd if=/dev/zero of=/dev/sdb bs=1M count=100 conv=notrunc # 立即读取，不加 sync dd if=/dev/sdb of=/tmp/read1.bin bs=1M count=100 # 检查是否全零 hexdump -C /tmp/read1.bin | head -5

如果读出来全零，先别急着下结论，执行sync再读一次：

sync dd if=/dev/sdb of=/tmp/read2.bin bs=1M count=100 hexdump -C /tmp/read2.bin | head -5

如果read2有数据而read1全零，说明问题出在缓存层，不是设备层。这是最常见的"假故障"。

4.3 复现步骤二：切换到 PIO 模式

第二步，进入 BIOS 把 SATA 模式从 AHCI 改成 IDE（即 PIO 兼容模式），重启后重复上面的写入测试。这时候你会观察到：

• 写入速度明显变慢（PIO 没有 DMA，全靠 CPU 搬）
• dmesg里出现ata1: PIO mode相关日志
• 如果盘老化严重，写入可能超时

在 PIO 模式下跑一个循环写入脚本：

for i in $(seq 1 50); do dd if=/dev/zero of=/dev/sdb bs=1M count=10 conv=notrunc 2>/dev/null echo "round $i exit=$?" done

如果某几轮exit=0但后续读取全零，恭喜你，复现成功。

4.4 复现步骤三：破坏 MBR 并观察 OS 反应

第三步，单独测试 MBR 的影响：

# 清空 MBR dd if=/dev/zero of=/dev/sdb bs=512 count=1 conv=notrunc # 尝试读取分区表 fdisk -l /dev/sdb # 尝试挂载 mount /dev/sdb1 /mnt 2>&1

你会看到fdisk报"未找到分区表"，mount报"设备不存在"。这时候任何基于分区的读取都会失败或返回零。如果脚本只检查dd的返回码，它依然会报 PASS。

4.5 参数计算：如何判断写入是否真的落盘

判断写入是否落盘，最可靠的方法是写入已知模式，再读回比对。不要写全零，因为全零和"未初始化"无法区分。

# 生成一个非零模式 head -c 1048576 /dev/urandom > /tmp/pattern.bin # 写入 dd if=/tmp/pattern.bin of=/dev/sdb bs=1M count=1 conv=fsync oflag=direct # 读回 dd if=/dev/sdb of=/tmp/verify.bin bs=1M count=1 iflag=direct # 比对 cmp /tmp/pattern.bin /tmp/verify.bin && echo "MATCH" || echo "MISMATCH"

这个方法的原理是：全零写入无法区分"写成功"和"没写"，而随机模式可以。cmp返回 MATCH 才代表真正落盘。

5. 常见问题与排查技巧实录

5.1 排查速查表

5.2 独家避坑技巧

技巧一：永远不要用全零做写入测试。全零是"未初始化"和"写成功"的共同结果，无法区分。用随机模式或递增模式，读回比对才能确认。

技巧二：老化测试脚本必须加oflag=direct,fsync。这两个参数是脚本"说真话"的前提。没有它们，脚本的 PASS 只是缓存层的 PASS。

技巧三：PIO 模式只用于诊断，不用于量产测试。PIO 的吞错机制会让测试结果不可信。如果必须用 PIO，至少要在每轮写入后加hdparm -F强制刷盘，并检查dmesg。

技巧四：MBR 测试要单独隔离。不要在同一次测试里既写 MBR 又写数据区，否则无法区分是哪一层出的问题。先测 MBR 读写，再测数据区读写。

技巧五：看dmesg比看脚本输出更重要。脚本的 PASS 是应用层视角，dmesg是内核视角。两者不一致时，永远相信dmesg。

5.3 一个真实的排查案例

我之前遇到过一次，脚本跑 200 轮全 PASS，但抽检读回来全零。排查过程：

1. 先sync再读，还是全零 → 排除缓存问题。
2. dmesg | grep ata，发现大量ata1.00: failed command: WRITE FPDMA QUEUED→ 控制器报错。
3. 检查 BIOS，发现 SATA 模式是 IDE → 切回 AHCI。
4. 重跑测试，dmesg干净，读回比对 MATCH。

根因是：IDE 模式下控制器对 NCQ 命令支持不完整，写入命令被静默丢弃，但dd的返回码依然是 0。脚本没错，OS 没错，错的是模式配置。

6. 从根上解决：让脚本和 OS 说同一套真话

6.1 脚本层面的加固

脚本要做的不是"检查命令返回码"，而是"验证数据一致性"。改造后的核心逻辑：

verify_write() { local dev=$1 local pattern=/tmp/pattern.bin local verify=/tmp/verify.bin head -c 1048576 /dev/urandom > $pattern dd if=$pattern of=$dev bs=1M count=1 conv=fsync oflag=direct 2>/dev/null || return 1 dd if=$dev of=$verify bs=1M count=1 iflag=direct 2>/dev/null || return 1 cmp -s $pattern $verify || return 1 return 0 }

这个函数只有在"写入成功 + 读回一致"时才返回 0。任何一层出问题都会被抓到。

6.2 OS 层面的配置检查

在测试开始前，先确认系统配置：

# 检查 SATA 模式 dmesg | grep -i "ahci\|ata.*mode" # 检查设备是否被正确识别 lsblk -o NAME,SIZE,TYPE,MOUNTPOINT # 检查分区表 fdisk -l /dev/sdb # 检查 SMART 健康 smartctl -H /dev/sdb

这四步能在测试前排除大部分环境问题。

6.3 硬件层面的老化判断

如果脚本和 OS 都加固了，还是出现全零，那就要怀疑硬件。重点看：

• smartctl -a里的Reallocated_Sector_Ct、Pending_Sector_Ct
• dmesg里的I/O error、medium error
• 写入速度是否异常下降

老化的盘在 PIO 模式下特别容易吞错，因为 PIO 没有 DMA 的错误校验机制。这时候换盘是唯一选择。

6.4 一个可复用的测试框架

把上面的经验整合成一个测试框架，核心是"三层验证"：

1. 命令层：检查dd返回码。
2. 数据层：读回比对，确认数据一致。
3. 内核层：检查dmesg，确认无隐藏错误。

三层都通过，才报 PASS。任何一层失败，记录详细日志并标记 FAIL。这样脚本说的 PASS 才是真的 PASS，OS 读到的数据才是真的数据。

我个人在实际操作中的体会是，这类"脚本和 OS 互相矛盾"的问题，九成以上不是谁在撒谎，而是验证的粒度太粗。脚本只看返回码，OS 只看读到的内容，中间的过程没人管。把验证粒度细化到"数据一致性"和"内核日志"这两个层面，绝大多数假故障都会现出原形。最后再分享一个小技巧：测试前先用hdparm -tT跑一遍基准，如果速度明显低于同型号盘，先别急着跑测试，先查硬件。