1. 为什么OOB这块“边角料”值得单独拎出来讲搞存储的人多少都有个共识NAND Flash 的 OOBOut-of-Band区域面积小得可怜却经常是整条链路上最容易翻车的地方。我见过太多项目主数据区读写跑得飞起一到坏块管理、ECC 校验、文件系统挂载就各种玄学报错最后刨根问底问题全压在 OOB 这几十个字节上。这篇内容就围绕 NAND Flash OOB 区域展开从数据纠错一路聊到文件系统层面的优化把这块“边角料”里藏着的门道掰开揉碎讲清楚。先说清楚它是什么。NAND Flash 的物理页分为主数据区Main Area和空闲区Spare Area后者就是 OOB。以常见的 SLC 小页 NAND 为例一页 2KB 主数据配 64 字节 OOBMLC 大页常见 4KB 主数据配 128 字节甚至 224 字节 OOB。这几十上百字节不是厂商随手留的冗余它承担着 ECC 校验码存放、坏块标记、文件系统元数据、磨损均衡计数等一系列关键职责。能做什么简单说没有 OOBNAND 的可靠性体系根本立不起来——纠错没地方放校验码坏块管理没地方打标记上层文件系统也没地方存自己的私有元信息。适合谁来参考如果你是驱动工程师、存储子系统开发者、嵌入式文件系统移植人员或者正在做 NAND 底层适配、量产测试、掉电恢复方案的技术人员这篇内容基本覆盖了你日常会踩的坑。哪怕你只是刚接触 NAND、想搞明白“为什么格式化之后坏块信息还在”这类问题也能从里面找到答案。我会按“整体设计思路—核心细节—实操落地—问题排查”的顺序往下走中间穿插参数计算和实测经验尽量做到看完就能对着自己的板子复现。2. 整体设计与思路拆解OOB 的职责边界怎么划2.1 OOB 区域的空间分配逻辑OOB 的分配不是拍脑袋决定的它背后有一套非常现实的约束。核心矛盾在于ECC 强度越高占用的 OOB 字节越多而坏块标记、文件系统元数据又必须留出固定位置。所以第一步永远是算账——先确定 ECC 方案再倒推剩余空间怎么切。以 2KB 页 64 字节 OOB 的 SLC 为例一个典型的分配方案是这样的ECC 校验码占 40 字节左右对应 BCH 8bit/540B 或类似强度坏块标记占 2 字节通常放在 OOB 第一个字节和最后一个字节各一份做冗余剩余 20 多字节留给文件系统私有数据比如 YAFFS2 的 tags、UBI 的 VID header 等。这个比例不是固定的MLC 因为误码率高ECC 往往要吃到 OOB 的一半以上留给上层的空间就被压缩得很厉害。这里有个容易被忽略的点OOB 的访问粒度。很多控制器支持“带 OOB 读”和“不带 OOB 读”两种模式前者把主数据和 OOB 一起搬到缓冲区后者只搬主数据。如果你在驱动里混用这两种模式很容易出现 OOB 数据没刷新、坏块标记读到旧值的问题。我的建议是坏块扫描和文件系统挂载阶段统一走带 OOB 读数据面读写可以按需选择但要在驱动层把缓冲区布局约定死别让上层去猜偏移。2.2 为什么 ECC 方案决定了 OOB 的“天花板”ECC 是 OOB 的第一大客户也是决定整个方案可行性的关键。NAND 的误码率随制程和擦写次数上升而恶化SLC 在寿命末期可能需要 8bit 甚至 12bit 纠错MLC 常见 24bit 到 40bitTLC 更是往 60bit 以上走。纠错强度每上一个台阶校验码长度就跟着涨OOB 的压力就更大。举个具体的账BCH 码在 512 字节数据块上做 8bit 纠错校验码大约 13 到 14 字节做 24bit 纠错校验码要 39 字节左右到 40bit直接奔着 65 字节去了。一页 4KB 主数据通常切成 8 个 512 字节的扇区每个扇区独立算 ECC那么 8bit 方案总共要 8×14≈112 字节24bit 方案要 8×39≈312 字节——后者已经超过很多 128 字节 OOB 的容量了。这就是为什么大页 MLC 的 OOB 往往做到 224 字节甚至更大本质是被 ECC 逼出来的。所以方案选型时的正确顺序是先根据 NAND 型号的 datasheet 拿到“每 512 字节需要的最大纠错位数”和“OOB 总容量”反算出 ECC 能占多少再看剩下的够不够放坏块标记和文件系统元数据。如果不够要么换更强但更省空间的 LDPC 方案同等纠错下校验开销通常比 BCH 小要么调整文件系统选型把元数据挪到主数据区去。这个顺序千万别搞反我见过先定了文件系统、结果发现 OOB 塞不下 ECC 校验码最后只能推倒重来的案例。2.3 坏块标记与文件系统元数据的共存策略坏块标记和文件系统元数据是 OOB 里的另外两个“住户”它们和 ECC 抢空间还互相影响。坏块标记的行业惯例是放在 OOB 的固定偏移通常是第 0 字节并且为了抗误判会在页内最后一个 OOB 字节再存一份镜像。上电扫描时读这两处只要有一处是非 0xFF 就判定为坏块。这个“双份冗余”的设计很关键因为单点读取一旦碰上偶发误码可能把好块误判成坏块损失一个块的容量事小量产时误判率上去了就是大问题。文件系统元数据这块不同方案差别很大。YAFFS2 把 tags 存在 OOB 里包含对象 ID、块内偏移、序列号等信息依赖 OOB 的固定布局UBI 则把 EC header 和 VID header 分别放在两个页的 OOB 里形成所谓的“双头”结构。这些设计的前提都是 OOB 有足够空间且驱动层能稳定地按偏移读写。实操中最大的坑是文件系统层和驱动层对 OOB 偏移的理解不一致比如驱动把 ECC 放在前 40 字节文件系统却以为从第 0 字节开始就是自己的地盘结果元数据把 ECC 覆盖了读的时候校验全错。解决办法只有一个——在驱动里把 OOB 布局定义成一份共享的宏或结构体文件系统层引用同一份定义绝不各写各的。3. 核心细节解析与实操要点ECC、坏块与元数据的落地3.1 ECC 校验码的生成与存放位置ECC 的生成流程本身不复杂数据写入前控制器或软件 ECC 引擎按扇区计算校验码追加到 OOB 对应偏移读取时重新计算并与存储的校验码比对不一致就尝试纠错。复杂的是存放位置的约定。常见做法是把 OOB 按扇区切分每个扇区的校验码紧跟在对应数据扇区之后。比如 2KB 页分 4 个 512 字节扇区OOB 前 4×1456 字节按顺序放 4 组校验码剩下的 8 字节留给坏块标记和元数据。这里有个实操细节值得强调ECC 校验码的存放偏移必须和硬件 ECC 引擎的预期一致。很多 SoC 的 NAND 控制器是硬件算 ECC 的它内部对“校验码放在 OOB 第几字节”有硬编码的假设你如果手动改了布局硬件纠错就会失效表现为读出来的数据全是错的但又不报 ECC 错误。我踩过这个坑当时以为是 NAND 坏了换了几片都一样最后翻控制器手册才发现 OOB 布局被我在驱动里改过。所以动 OOB 布局之前先确认硬件 ECC 引擎的约束软件 ECC 方案则自由得多但性能开销要自己扛。注意软件 ECC 在大页高纠错场景下 CPU 占用很可观实测 4KB 页 24bit BCH 纯软件纠错单核跑满也就几十 MB/s量产或高吞吐场景务必评估是否上硬件引擎或 LDPC。3.2 坏块标记的读写时机与抗误判设计坏块标记的读写时机是有讲究的。出厂坏块由厂商在 OOB 第 0 字节写非 0xFF 值标记使用过程中新产生的坏块由驱动在擦除失败或编程失败时补标。读取时机主要是上电初始化扫描和文件系统挂载前的坏块表构建。这里的关键是“只信双份、不信单份”——前面说的第 0 字节和最后字节双份冗余扫描时两处都读任一非 0xFF 即判坏。抗误判还有一层设计坏块标记一旦写入就不应该再被擦除。有些驱动在格式化时会顺手擦整个块包括 OOB结果把坏块标记擦没了坏块“复活”成好块后续写入必然失败。正确做法是格式化时跳过坏块或者只擦主数据区不动 OOB 的坏块标记位。另外新坏块的补标要谨慎编程失败可能是偶发的建议连续失败两次再标记避免把好块误杀。这个阈值可以配置量产环境我一般设成 2实验室调试设成 1 方便快速暴露问题。3.3 文件系统元数据在 OOB 中的布局约束文件系统把元数据塞进 OOB本质是借这块“免费”空间降低主数据区的管理开销。但借归借约束得守。以 UBI 为例EC header 存在每个物理擦除块第一个页的 OOB 里VID header 存在第二个页的 OOB 里两者偏移固定且要求 OOB 至少有 64 字节可用空间。如果你的 ECC 吃掉了 56 字节只剩 8 字节UBI 根本跑不起来这时候要么换 ECC 方案要么改用把元数据放主数据区的文件系统。实操中最容易出问题的是 OOB 的“可用空间”计算。很多 datasheet 标的 OOB 容量是物理容量但控制器可能保留几个字节做内部用途实际可用要打折扣。我的经验是按 datasheet 容量减去 ECC 占用再留 4 到 8 字节余量来规划别把空间算到极限。另外文件系统元数据的写入要和 ECC 生成顺序协调好——先算 ECC 填进 OOB再写文件系统元数据到剩余偏移顺序反了会把校验码覆盖掉。4. 实操过程与核心环节实现从裸片到文件系统挂载4.1 环境准备与裸片信息确认动手之前先把 NAND 的“身份证”摸清楚。通过读 ID 命令拿到厂商和型号对照 datasheet 确认几个关键参数页大小、OOB 大小、块大小、每 512 字节最大纠错位数、擦写寿命。这些参数决定了后面所有计算。我一般会写个小脚本上电后自动读 ID 并打印参数表避免手工查表出错。/* 读取 NAND ID 并解析关键参数的示意逻辑 */ uint8_t id[5]; nand_read_id(id); printf(Maker:0x%02X Device:0x%02X\n, id[0], id[1]); /* 根据 id 查表得到 page_size / oob_size / ecc_bits */参数确认后先做一次全片坏块扫描把坏块位置记录下来。扫描时用带 OOB 读模式读每个块第一页和最后一页的 OOB 第 0 字节与最后字节双份判定。扫描结果存成坏块表后续所有操作都基于这张表跳过坏块。这一步别偷懒我见过跳过扫描直接格式化的结果文件系统把数据写进坏块挂载时各种校验失败排查半天才发现是坏块没避开。4.2 ECC 参数计算与 OOB 布局落地假设手头是一片 4KB 页、128 字节 OOB 的 MLCdatasheet 要求每 512 字节 24bit 纠错。先算 ECC 开销4KB 分 8 个 512 字节扇区BCH 24bit 每扇区校验码约 39 字节8 扇区共 312 字节——超了。这时候两个选择换 LDPC同等纠错校验开销约减半约 156 字节还是紧或者降低纠错位数到 16bit每扇区约 26 字节8 扇区 208 字节仍超。现实是这片 NAND 的 128 字节 OOB 根本撑不起 24bit BCH 全页纠错datasheet 里大概率写的是“建议使用 LDPC”或者“OOB 含控制器保留区”。这就是为什么选型阶段必须把账算在前面。换一片 4KB 页、224 字节 OOB 的 MLC24bit BCH 的 312 字节还是超但 LDPC 的约 156 字节就放得下了剩余 68 字节够放坏块标记2 字节和文件系统元数据UBI 需要 64 字节刚好卡线建议再留余量或换更大 OOB 的片子。布局定下来后在驱动头文件里定义结构体/* OOB 布局定义驱动与文件系统层共享 */ #define OOB_ECC_OFFSET 0 #define OOB_ECC_LEN 156 #define OOB_BBM_OFFSET 156 #define OOB_BBM_LEN 2 #define OOB_FS_OFFSET 158 #define OOB_FS_LEN (224 - 158)这份定义是唯一真相来源任何模块要用 OOB 都引用它杜绝偏移写死在各处。4.3 坏块表构建与文件系统格式化坏块表构建完成后格式化前先做一次“坏块跳过”验证随机挑几个坏块尝试写入并确认驱动确实跳过了它们。验证通过再格式化。以 UBI 为例格式化时会写 EC header 和 VID header 到 OOB这时候要确认 ECC 已经正确生成且没被覆盖。格式化完成后挂载挂载过程会读 OOB 里的 UBI 头如果 ECC 校验失败或头信息错乱挂载会直接报错。实测记录某次在 224 字节 OOB 的片子上跑 UBI挂载报 “bad EC header”。排查发现是驱动里 ECC 占了前 160 字节而 UBI 的 EC header 预期从偏移 0 开始读两者冲突。调整布局把 ECC 挪到 OOB 后半段、UBI 头放前半段后恢复正常。这个案例说明文件系统对 OOB 偏移的预期是硬性的布局设计必须以文件系统文档为准ECC 位置让路。4.4 掉电恢复场景下的 OOB 一致性掉电是 NAND 的老对手OOB 在掉电场景下的一致性尤其脆弱。写入过程中掉电可能出现主数据写了一半、OOB 校验码没写全的情况读的时候 ECC 必然失败。应对策略是“先写 OOB 后写主数据”还是反过来行业常见做法是先写主数据再写 OOB因为 OOB 里的校验码是对主数据的描述主数据没落盘校验码就没意义但这样掉电时可能出现主数据新、校验码旧读出来纠错失败。更稳的做法是借助文件系统的日志或 UBI 的原子更新机制把“数据OOB”作为一个事务处理掉电后靠日志回滚。纯裸片操作没有这层保护只能靠上层重试和坏块隔离兜底。5. 常见问题与排查技巧实录5.1 典型故障速查表现象可能原因排查方向读数据全错但不报 ECC 错OOB 布局与硬件 ECC 引擎预期不符对照控制器手册核对校验码偏移格式化后坏块“复活”格式化擦除了 OOB 坏块标记检查格式化流程是否跳过 OOB 标记位文件系统挂载报头错误文件系统元数据偏移被 ECC 覆盖核对文件系统文档要求的 OOB 偏移偶发单比特误判坏块坏块标记只读了单份改为双份读取任一非 0xFF 判坏高纠错下吞吐骤降软件 ECC 计算开销过大评估硬件 ECC 或 LDPC 方案5.2 独家避坑心得第一个心得OOB 布局一定要在项目早期冻结并写进接口文档。我经历过中途改布局导致已量产设备无法读取旧数据的惨案代价是整批返工。第二个心得坏块扫描结果要持久化别每次上电重扫重扫不仅慢还可能因为偶发误码得到不一致的结果。第三个心得调试阶段把 OOB 的原始内容 dump 出来看比任何日志都直观——坏块标记、ECC 校验码、文件系统头各占哪几个字节一眼就能对上很多“玄学”问题 dump 一次就现原形。提示dump OOB 时用带 OOB 读模式且注意字节序不同控制器搬移 OOB 到缓冲区的顺序可能不同别把偏移搞反了。5.3 性能与可靠性的平衡取舍最后聊个实操中绕不开的取舍ECC 越强越可靠但校验码越长、计算越慢OOB 空间越省给文件系统元数据管理越灵活但 ECC 余量越紧张。我的经验是消费级场景优先保可靠性ECC 按 datasheet 上限配OOB 不够就换更大 OOB 的片子成本敏感场景可以适度降 ECC 强度但必须做寿命末期的误码率实测别拿理论值赌。这个平衡没有标准答案只能靠实测数据说话我一般会在样品阶段跑一轮全寿命擦写记录误码率曲线再定最终参数。这个内容后续还可以往 LDPC 软判决、OOB 加密存储、多平面操作下的 OOB 一致性这些方向扩展每个方向都够单独写一篇。就我个人的体会而言OOB 这块地方虽小但它把 ECC、坏块管理、文件系统三层紧紧绑在一起任何一层的疏忽都会在另外两层放大成故障把它吃透NAND 底层的很多问题就迎刃而解了。