1. 一个让老运维都挠头的经典悬案脚本说 PASSOS 读全零——这个标题我第一次看到的时候脑子里立刻浮现出几年前在机房熬夜排查的那一幕。当时一块盘在自动化老化测试脚本里跑得好好的日志里全是绿油油的 PASS结果一装系统分区表读出来全是 0x00整块盘跟被格式化过一样干净。你说脚本撒谎吧它确实读到了数据你说 OS 撒谎吧它读出来的也确实是零。那到底是谁在撒谎这个问题的核心其实落在几个关键词上脚本、OS、AHCI、PIO、MBR。这几个词凑在一起基本就把场景框死了——一块 SATA 盘通过 AHCI 控制器接入测试脚本可能走的是 PIO 或者某种兼容模式去读写而操作系统启动时走的是 AHCI 原生驱动两者对同一块盘的看法出现了分歧。MBR 则是那个被读成全零的倒霉蛋它是磁盘第一个扇区LBA 0里的 512 字节包含引导代码和分区表一旦读出来全是零系统就彻底找不到盘上的分区了。这篇文章我想干的事不是给你一个标准答案就完事而是把这类问题的排查思路、底层原理、实操手法完整地摊开讲。适合谁看做设备老化测试的、写自动化测试脚本的、搞存储固件或者嵌入式系统的、以及所有被脚本和系统读数不一致坑过的工程师。哪怕你现在没遇到看完之后下次遇到类似两边读数对不上的问题你至少知道该从哪几个维度去切。我会从整体设计思路讲起然后拆解 AHCI 和 PIO 这两条路径的本质差异接着讲 MBR 为什么会被读成全零再给出一套完整的实操排查流程最后把我踩过的坑和常见问题整理成速查表。全程说人话能抄作业的地方直接给你命令和参数。2. 整体设计思路为什么会出现两边读数不一致2.1 先搞清楚谁在读盘这件事很多人一上来就纠结谁撒谎但真正该问的第一个问题是脚本和 OS 到底是不是在用同一条路径读盘这个问题不搞清楚后面全是瞎猜。一块 SATA 盘挂到主板上CPU 想读它的数据中间要经过这么一条链路CPU → 内存 → 控制器AHCI 或 IDE 兼容模式→ SATA 盘。控制器有两种工作模式一种是AHCIAdvanced Host Controller Interface一种是IDE 兼容模式也叫 Legacy 模式。这两种模式对上层软件呈现的寄存器接口完全不一样。脚本如果是在 DOS 环境、或者某个精简的测试固件里跑的它很可能走的是PIOProgrammed I/O方式也就是 CPU 亲自一个字节一个字节地从控制器数据端口搬数据。这种方式慢但简单不依赖中断和 DMA在裸机或者早期测试环境里特别常见。而操作系统启动后加载的是 AHCI 原生驱动走的是DMADirect Memory Access控制器自己把数据搬到内存CPU 只管发命令。关键点PIO 和 DMA 读的是同一块盘、同一个 LBA但走的寄存器、命令格式、甚至对某些边界情况的处理都可能不同。这就是两边读数不一致的温床。2.2 为什么脚本会说 PASS脚本说 PASS通常意味着它完成了预设的读写校验流程比如写一个 pattern 进去再读出来比对一致就 PASS。但这里有个巨大的陷阱脚本校验的可能只是它自己那条路径上的数据一致性而不是磁盘上真实的数据。举个我实际遇到的例子。某老化测试脚本的逻辑是这样的往 LBA 0 写一个已知的 MBR 模板然后读回来比对。脚本走 PIO写完立刻读读到的确实是刚写进去的内容PASS。但问题是这个写可能只写进了控制器的缓存或者写进了磁盘的易失性缓存DRAM cache并没有真正落盘。等脚本退出、系统启动、AHCI 驱动重新初始化控制器时缓存被丢弃磁盘上那个扇区可能还是旧的——甚至是全零。还有一种更隐蔽的情况脚本读的 LBA 和 OS 读的 LBA 根本不是同一个物理位置。这在有地址映射或者容量裁剪的盘上会发生比如某些盘对前几个扇区做了特殊处理或者固件里做了 HPAHost Protected Area隐藏区域。脚本按逻辑地址读OS 按物理地址读读出来的东西自然对不上。2.3 方案选型的核心考量面对这种问题排查方案的设计要围绕三个原则第一隔离变量。不要一上来就怀疑盘坏了先把读盘路径这个变量固定住。让脚本和 OS 走同一条路径读同一个 LBA看结果是否一致。如果一致说明问题出在路径差异上如果不一致才可能是盘或固件的问题。第二可复现。老化测试最怕的就是偶发。如果这个问题只在特定温度、特定电压、特定上电次数后出现那必须设计一个能稳定复现的流程否则修了也不知道修没修好。第三留证据。每一步读出来的原始数据都要落盘保存最好带上时间戳和 LBA 地址。后面分析的时候这些原始数据就是案发现场。我一般会准备一个 U 盘里面放两个工具一个是在 DOS 或 EFI Shell 下跑的裸机读写工具走 PIO 或 EFI Block I/O一个是 Linux Live 环境走 AHCI 原生驱动。两边读同一个 LBA把结果 dump 出来对比。这个对比表往往一眼就能看出问题。3. 核心细节解析AHCI、PIO、MBR 到底在干什么3.1 AHCI 和 PIO 的本质差异要理解为什么两边读数会不一样必须把 AHCI 和 PIO 的差异讲透。我用一个生活化的类比PIO 就像你去银行柜台柜员CPU亲自一笔一笔地帮你办业务每笔都要经过柜员的手DMA 就像你开了网银银行系统控制器自己把账转了你只管最后看结果。具体到寄存器层面PIO 模式下读数据要往Data Port0x1F0这个端口反复读每次读 2 字节或 4 字节读一个扇区要读 256 次512 字节 / 2 字节。而 AHCI 模式下你要在内存里建一个Command List填好Command Header、Command Table、PRDTPhysical Region Descriptor Table然后写PxCIPort Command Issue寄存器控制器自己去搬数据搬完发中断。这两条路径的差异点在于命令格式不同PIO 用的是传统的 ATA 命令寄存器Features、Sector Count、LBA Low/Mid/High、Device、CommandAHCI 用的是 FISFrame Information Structure和 Command Table。数据搬运方式不同PIO 靠 CPU 搬DMA 靠控制器搬。缓存处理不同PIO 写完如果不发 FLUSH CACHE数据可能停在盘缓存里AHCI 驱动通常会正确处理缓存刷新但也不是绝对的。错误处理不同PIO 读失败看 Status 寄存器的 ERR 位AHCI 读失败看 PxISPort Interrupt Status和 PxTFDTask File Data。实操心得很多脚本 PASS、OS 读零的案例根因就是脚本走 PIO 写完没发 FLUSH CACHE或者发了但没等 BSY 位清零就退出了。盘缓存里的数据还没落盘脚本就报 PASS 了。3.2 MBR 为什么会被读成全零MBR 位于 LBA 0占 512 字节。它的结构是前 446 字节是引导代码接着 64 字节是 4 个分区表项每个 16 字节最后 2 字节是签名 0x55AA。如果 OS 读出来全是零意味着这 512 字节一个有效数据都没有。可能的原因有这么几类第一类写入根本没落盘。脚本写 MBR 的时候数据进了盘的易失性缓存脚本报 PASS 后断电或复位缓存丢失LBA 0 还是原来的全零。这种情况在老化测试里特别常见因为测试经常涉及反复上下电。第二类写到了错误的 LBA。有些盘的固件在收到写命令后如果 LBA 超出实际容量或者命中了某个保留区域会静默丢弃写命令返回成功但不实际写入。脚本以为写成功了其实盘根本没动。第三类读的时候地址映射变了。某些盘支持LBA 重映射或者Trim之类的特性如果脚本写完之后触发了某种映射变更OS 再读 LBA 0 时可能读到了被重映射后的位置。第四类控制器模式切换导致寄存器解释不同。这个是最玄学的。脚本在 IDE 兼容模式下写 MBROS 在 AHCI 模式下读。如果 BIOS 在切换模式时没有正确复位控制器或者盘的某些状态没清干净读出来的数据就可能不对。我遇到过最离谱的一次是盘的固件在 PIO 模式下对 LBA 0 的写命令有 bug写进去的数据被截断了只写了前 256 字节后 256 字节保持全零。脚本只校验了前 256 字节因为它的 buffer 只开了 256PASSOS 读完整 512 字节发现后半段全零分区表解析失败。3.3 老化测试脚本的典型结构既然标题里提到了设备老化测试全自动执行脚本我顺便把这类脚本的典型结构讲一下方便你对照自己的场景。一个完整的老化测试脚本通常包含这几个阶段初始化阶段枚举设备识别盘的类型、容量、固件版本记录基线信息。写入阶段往指定 LBA 写入测试 patternpattern 可以是固定值、递增序列、随机数或者模拟的 MBR/GPT 结构。读取校验阶段读回数据和写入的 pattern 比对。循环阶段重复写入-读取-校验可能配合上下电、温度循环、振动等应力条件。报告阶段汇总 PASS/FAIL记录异常 LBA 和错误码。问题往往出在写入阶段和读取校验阶段之间没有做缓存刷新以及校验的 buffer 大小和实际扇区大小不匹配。这两个坑我在后面会详细讲怎么排查。4. 实操过程一步步定位到底是谁在撒谎4.1 第一步固定读盘路径做对照实验排查的第一步永远是让两边走同一条路径。具体做法准备一个 Linux Live U 盘比如 Ubuntu 或者任何一个带hdparm、dd、smartctl的发行版启动后先确认盘在 AHCI 模式下被识别lspci | grep -i sata dmesg | grep -i ahci lsblk -o NAME,SIZE,TYPE,MOUNTPOINT假设目标盘是/dev/sdb先用dd读 LBA 0 的 512 字节dd if/dev/sdb of/tmp/lba0_ahci.bin bs512 count1 skip0 hexdump -C /tmp/lba0_ahci.bin然后在 BIOS 里把 SATA 模式改成 IDE 兼容模式或者用 DOS 启动盘跑裸机工具再读同一个 LBAdd if/dev/sdb of/tmp/lba0_ide.bin bs512 count1 skip0 hexdump -C /tmp/lba0_ide.bin把两个文件做二进制比对cmp -l /tmp/lba0_ahci.bin /tmp/lba0_ide.bin | head -20如果两个文件完全一致说明路径差异不是根因问题在盘或固件。如果不一致那基本可以锁定是 AHCI 和 IDE/PIO 路径的差异导致的。注意切换 BIOS 模式后一定要完全断电再上电不要只重启。有些主板在重启时不会真正复位 SATA 控制器导致盘的状态残留。4.2 第二步检查缓存刷新和 BSY 位如果对照实验发现两边读数不一致下一步就是查缓存刷新。在 Linux 下可以用hdparm强制刷新盘缓存hdparm -F /dev/sdb-F是 Flush Cache它会发 FLUSH CACHE 命令给盘等盘把缓存里的数据全部落盘后才返回。刷完之后再读 LBA 0看数据是否变化。如果你的脚本是裸机程序那就要检查代码里有没有发0xE7FLUSH CACHE命令以及发完之后有没有轮询 Status 寄存器的 BSY 位直到清零。我见过太多脚本写完数据直接读读到了缓存里的数据就报 PASS根本没等落盘。一个正确的 PIO 写流程应该是这样的// 伪代码展示关键步骤 write_lba(0, buffer, 512); // 写数据到 Data Port wait_bsy_clear(); // 等 BSY 清零 send_command(0xE7); // FLUSH CACHE wait_bsy_clear(); // 等 FLUSH 完成 check_status_err(); // 检查 ERR 位如果少了send_command(0xE7)和后面的等待数据就可能停在缓存里。4.3 第三步确认 LBA 和扇区大小这一步经常被忽略但非常关键。确认脚本写的 LBA 和 OS 读的 LBA 是同一个物理位置。先看盘的逻辑扇区大小hdparm -I /dev/sdb | grep -i sector size如果盘是 4K 原生扇区4096 字节但脚本按 512 字节扇区去写那 LBA 的换算就会错位。比如脚本写 LBA 0512 字节偏移 0OS 读 LBA 04096 字节偏移 0虽然都叫 LBA 0但实际覆盖的物理范围不一样。再看盘的实际容量和脚本声明的容量是否一致hdparm -N /dev/sdb blockdev --getsize64 /dev/sdbhdparm -N会显示盘的 HPAHost Protected Area信息。如果盘有隐藏区域脚本按可见容量写OS 按物理容量读边界处的 LBA 就会错位。4.4 第四步抓取原始数据和错误日志如果前三步都没找到根因那就上重武器抓原始数据。在 Linux 下可以用smartctl看盘的错误日志smartctl -a /dev/sdb smartctl -l error /dev/sdb smartctl -l selftest /dev/sdb重点看ATA Error Count、Reallocated Sector Count、Current Pending Sector这几个属性。如果 Reallocated Sector Count 在测试过程中增长说明盘有坏道写进去的数据被重映射了读出来自然是零或者旧数据。同时在脚本侧也要加日志。每次读写都记录 LBA、数据的前 16 字节、Status 寄存器的值、时间戳。这些日志在事后分析时价值极高。我一般会写一个简单的 Python 脚本来做数据比对和可视化import binascii def compare_dumps(file_a, file_b): with open(file_a, rb) as fa, open(file_b, rb) as fb: data_a fa.read() data_b fb.read() if len(data_a) ! len(data_b): print(f长度不一致: {len(data_a)} vs {len(data_b)}) return diff_count 0 for i, (a, b) in enumerate(zip(data_a, data_b)): if a ! b: diff_count 1 if diff_count 20: print(f偏移 {i}: {a:02x} vs {b:02x}) print(f总差异字节数: {diff_count}) compare_dumps(/tmp/lba0_ahci.bin, /tmp/lba0_ide.bin)这个脚本能快速告诉你两个 dump 文件在哪些偏移处不一致差异是全零还是随机值对判断根因很有帮助。4.5 第五步复现和验证找到疑似根因后必须设计一个能稳定复现的流程。比如怀疑是缓存刷新问题那就写一个脚本故意在写完 MBR 后立即断电再上电读 LBA 0看是否全零。如果能稳定复现就说明根因找对了。验证的时候要注意控制变量。每次只改一个条件比如测试 A写完发 FLUSH CACHE再断电读 LBA 0。测试 B写完不发 FLUSH CACHE再断电读 LBA 0。测试 C写完发 FLUSH CACHE等 10 秒再断电读 LBA 0。对比 A、B、C 的结果就能确认 FLUSH CACHE 和等待时间对数据落盘的影响。5. 常见问题与排查技巧实录5.1 常见问题速查表现象可能原因排查方法解决方向脚本 PASSOS 读 LBA 0 全零写数据未落盘停在盘缓存脚本加 FLUSH CACHE等 BSY 清零补发 0xE7 命令并等待脚本和 OS 读数部分不一致扇区大小不匹配512 vs 4096hdparm -I查扇区大小统一按物理扇区大小读写特定 LBA 读出来总是零坏道被重映射smartctl -a看重映射计数标记坏道更换盘或屏蔽 LBA切换 AHCI/IDE 后数据变化控制器模式切换未复位完全断电再上电BIOS 里正确复位控制器老化测试偶发 FAIL温度/电压导致盘行为异常记录温度和电压做应力曲线调整测试条件或筛选盘脚本读到的数据和写入的不一样写命令被静默丢弃检查 LBA 是否超出容量确认容量和 HPA 设置OS 报 MBR 签名错误0x55AA 被覆盖或未写入hexdump看最后 2 字节检查写入 buffer 边界5.2 独家避坑技巧技巧一永远不要相信写完立即读的结果。写完数据后至少等一个 FLUSH CACHE 完成再读。如果盘支持最好等盘主动上报缓存已刷新的状态。技巧二校验 buffer 要开满一个完整扇区。我见过太多脚本只校验前 256 字节结果后半段全零都没发现。校验的时候buffer 大小必须是扇区大小的整数倍而且要和实际读写的大小一致。技巧三上下电测试要留足掉电时间。有些盘的缓存掉电需要几百毫秒才能完全丢失。如果掉电时间太短缓存里的数据可能还没丢下次上电读出来还是旧数据导致误判。我一般会等至少 2 秒再上电。技巧四用 SMART 数据做趋势分析。单次 SMART 读数意义不大但如果在老化测试过程中持续记录就能看出趋势。比如 Reallocated Sector Count 从 0 涨到 5说明盘在测试过程中产生了坏道这批盘可能有问题。技巧五脚本日志要带 LBA 和原始数据。不要只记 PASS/FAIL要记每次读写的 LBA、数据摘要比如 CRC32、Status 寄存器值。出问题的时候这些日志就是破案的关键。5.3 一个真实的排查案例最后分享一个我亲身经历的案例。某批盘在老化测试中脚本全部 PASS但装系统时 30% 的盘报 MBR 错误。我们按上面的流程排查第一步对照实验发现 AHCI 和 IDE 模式下读 LBA 0 结果不一致。IDE 模式下读出来是正常的 MBRAHCI 模式下读出来全零。第二步检查缓存刷新发现脚本确实发了 FLUSH CACHE但发完之后没有等 BSY 清零就退出了。第三步查扇区大小发现这批盘是 4K 原生扇区但脚本按 512 字节扇区写。写 LBA 0 的时候实际上只写了 4K 扇区的前 512 字节后 3584 字节没动。第四步抓 SMART 数据发现 Reallocated Sector Count 正常排除坏道。第五步复现验证。我们改脚本按 4K 扇区写完整的 MBR 结构并且发完 FLUSH CACHE 后等 BSY 清零。再跑老化测试装系统全部正常。根因就是扇区大小不匹配 缓存刷新不完整。脚本按 512 字节写盘按 4K 扇区处理写命令只覆盖了部分扇区加上缓存没刷干净AHCI 驱动重新初始化后读到的就是全零。这个案例告诉我们脚本说 PASS和OS 读全零可以同时为真因为脚本校验的范围和 OS 读取的范围根本不一样。脚本只校验了它写的那 512 字节OS 读的是完整的 4K 扇区后 3584 字节本来就是零。6. 从根因出发如何设计一个不会撒谎的测试脚本6.1 写入阶段的设计要点设计一个可靠的写入阶段核心是确保数据真正落盘并且覆盖完整的物理扇区。具体做法先查询盘的逻辑扇区大小和物理扇区大小按物理扇区大小对齐写入。写入 buffer 的大小必须是物理扇区大小的整数倍。写完一个扇区后发 FLUSH CACHE等 BSY 清零再写下一个。如果盘支持 FUAForce Unit Access写命令优先用 FUA它能让数据直接落盘绕过缓存。在 Linux 下可以用dd的oflagdirect来绕过页缓存但注意这绕的是 OS 的页缓存不是盘的缓存。盘的缓存还是要靠 FLUSH CACHE 或者 FUA。# 按 4K 扇区写direct I/O写完 sync dd if/tmp/mbr_4k.bin of/dev/sdb bs4096 count1 seek0 oflagdirect sync hdparm -F /dev/sdb6.2 读取校验阶段的设计要点读取校验阶段的核心是读回完整扇区并且和写入的数据做逐字节比对。具体做法读取 buffer 大小和写入 buffer 大小一致都是物理扇区大小的整数倍。读之前先发 FLUSH CACHE确保盘缓存里的数据已经落盘。比对的时候记录第一个不一致的偏移和值方便定位。如果盘支持读的时候也用 direct I/O避免 OS 页缓存干扰。# 读回 4K 扇区direct I/O dd if/dev/sdb of/tmp/readback_4k.bin bs4096 count1 skip0 iflagdirect cmp /tmp/mbr_4k.bin /tmp/readback_4k.bin6.3 循环和应力阶段的设计要点老化测试的循环阶段要模拟真实使用场景中的各种应力条件上下电循环每次写完数据后完全断电等至少 2 秒再上电读回。温度循环在高温比如 60°C和低温比如 0°C下分别跑读写测试。振动测试在振动台上跑测试看是否有偶发读写错误。电压拉偏在标称电压的 ±10% 范围内跑测试看盘的稳定性。每个应力条件下都要记录 SMART 数据和错误日志。如果某个条件下错误率明显上升说明盘的裕量不足。6.4 报告阶段的设计要点报告阶段要输出足够详细的信息方便事后分析每个 LBA 的读写次数、PASS/FAIL 次数。每次 FAIL 的原始数据 dump。SMART 属性的时间序列。测试环境的温度、电压、上电次数。我一般会把报告输出成 CSV 或者 JSON方便用脚本做进一步分析。比如用 pandas 做趋势图import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(aging_test_report.csv) df[timestamp] pd.to_datetime(df[timestamp]) df.plot(xtimestamp, yreallocated_sector_count) plt.savefig(smart_trend.png)7. 一些容易被忽略的底层细节7.1 AHCI 的 Command List 和 PRDT如果你要自己写 AHCI 驱动或者调试 AHCI 相关的问题必须理解 Command List 和 PRDT 的结构。Command List 是一块内存区域每个端口有一个包含 32 个 Command Header。每个 Command Header 指向一个 Command TableCommand Table 里包含命令 FIS 和 PRDT。PRDT 描述数据缓冲区在物理内存中的位置和长度。一个常见的 bug 是 PRDT 的条目数不够导致大数据传输时数据被截断。比如你要读 4K 数据但 PRDT 只描述了一个 512 字节的缓冲区那控制器只会搬 512 字节剩下的数据丢失。注意PRDT 的每个条目描述的是一个物理内存区域不能跨页。如果缓冲区跨页必须拆成多个 PRDT 条目。7.2 PIO 的 Status 寄存器轮询PIO 模式下每次读写都要轮询 Status 寄存器。Status 寄存器的关键位BSYbit 7控制器忙不能发新命令。DRDYbit 6设备就绪。DRQbit 3数据请求表示可以读写数据了。ERRbit 0错误。正确的轮询顺序是等 BSY 清零 → 等 DRQ 置位 → 读写数据 → 等 BSY 清零 → 检查 ERR。很多脚本的 bug 是只等了 DRQ没等 BSY 清零或者没检查 ERR。这会导致在盘还没准备好的时候就发下一个命令数据错乱。7.3 MBR 和 GPT 的边界虽然标题里说的是 MBR但实际场景中很多盘用的是 GPT。GPT 的头部在 LBA 1保护性 MBR 在 LBA 0。如果脚本只写了 LBA 0 的 MBR没写 LBA 1 的 GPT 头OS 读的时候会报 GPT 错误。GPT 头的结构是签名 EFI PART8 字节、版本4 字节、头部大小4 字节、CRC324 字节、保留4 字节、当前 LBA8 字节、备份 LBA8 字节、第一个可用 LBA8 字节、最后一个可用 LBA8 字节、磁盘 GUID16 字节、分区表起始 LBA8 字节、分区表项数4 字节、分区表项大小4 字节、分区表 CRC324 字节。如果脚本写 GPT 头的时候 CRC32 算错了OS 会认为 GPT 头损坏回退到 MBR 解析结果 MBR 也是空的就报全零。7.4 盘的缓存策略不同盘的缓存策略不一样。有些盘默认开启写缓存有些默认关闭。可以用hdparm -W查询和设置hdparm -W /dev/sdb # 查询 hdparm -W 0 /dev/sdb # 关闭写缓存 hdparm -W 1 /dev/sdb # 开启写缓存在老化测试中我建议关闭写缓存或者每次写完都发 FLUSH CACHE。这样虽然慢但能确保数据真正落盘避免脚本 PASS、OS 读零的假象。8. 工具选型和环境准备8.1 硬件工具SATA 协议分析仪如果条件允许用协议分析仪抓 AHCI 和 PIO 的完整命令流能直接看到控制器和盘之间的交互。这是最彻底的排查手段但成本高。可编程电源做电压拉偏测试用能精确控制电压。温箱做温度循环测试用。振动台做振动测试用。如果只是排查软件层面的问题这些硬件不是必须的。但如果是批量老化测试建议至少配一个可编程电源和温箱。8.2 软件工具Linux Live U 盘带hdparm、smartctl、dd、hexdump、cmp。DOS 启动盘带裸机读写工具比如mhdd、victoria。EFI Shell带 EFI Block I/O 工具能在 UEFI 环境下读写盘。Python 环境做数据分析和可视化。8.3 环境准备清单项目用途备注Linux Live U 盘AHCI 模式读写推荐 Ubuntu 或 DebianDOS 启动盘PIO/IDE 模式读写用 FreeDOS 或 MS-DOSEFI Shell U 盘UEFI 环境读写从主板厂商获取SATA 协议分析仪抓命令流可选成本高可编程电源电压拉偏批量测试建议配温箱温度循环批量测试建议配Python 3数据分析带 pandas、matplotlib9. 最后的经验分享写到这里我想再强调几个我在实际工作中反复验证过的点。第一脚本 PASS不等于数据正确。脚本的校验逻辑如果和 OS 的读取逻辑不一致两边可以同时正确但结果不同。设计测试脚本的时候一定要站在 OS 的角度想一遍OS 会怎么读这块盘会读多大会校验什么第二缓存是最大的敌人。无论是盘的缓存、控制器的缓存还是 OS 的页缓存都可能让写完立即读的结果失真。做可靠性测试的时候能关的缓存都关掉不能关的就用 FLUSH CACHE 或 FUA 强制落盘。第三扇区大小一定要对齐。512e 和 4Kn 的盘混在一起用是很多诡异问题的根源。测试之前先查清楚盘的扇区大小按物理扇区对齐读写。第四日志要详细到能复现。出问题的时候光看 PASS/FAIL 没用要看 LBA、原始数据、Status 寄存器、时间戳。这些信息越全定位越快。第五复现是验证根因的唯一标准。找到疑似根因后一定要设计一个能稳定复现的流程。如果复现不了说明根因可能找错了或者还有别的因素没考虑到。这个脚本说 PASS、OS 读全零的问题表面上看是谁在撒谎实际上是两边看的是不是同一个东西。把读盘路径、扇区大小、缓存策略、LBA 映射这几个变量固定住答案自然就出来了。希望这篇东西能帮到正在被类似问题折磨的你。