1.1 主机看到的盘：可覆盖写、按扇区寻址

主机侧的接口从几十年前的机械硬盘继承而来，语义非常朴素：整个盘是 0 ~ N-1 号逻辑块（LBA）组成的线性数组，读第 n 块就是把第 n 块的内容取出来，写第 n 块就是把第 n 块的内容换掉。文件系统（ext4、FAT、NTFS、F2FS）建立在这套语义之上，它默认三件事：

• 可以原地覆盖：改文件里一个字节，就直接把那个扇区重写一遍，不需要先擦除，也不影响别的扇区。
• 最小单位是扇区：读写粒度是 512 B 或 4 KB，跟「块」「页」这些物理概念没有任何约定关系。
• 删除只是改元数据：删掉一个文件，文件系统把它的块标记为空闲，并不要求存储设备立刻做什么动作，更不会通知设备「这几块以后不用了」。

第三点是后面所有麻烦的伏笔：文件系统知道哪些逻辑块已经没用了，但它默认不会告诉存储设备。设备这边只能看到「主机又写了这个 LBA」，根本无从判断上一次写的那份数据是不是已经作废。

1.2 NAND 真实的样子：按页写、按块擦、有寿命

NAND 这边是另一套规则，而且是硬约束，没有商量余地：

• 写以页为单位：一次编程的最小单位是一页，典型值 4 KB 到 16 KB（大容量 TLC 器件常见 16 KB）。写之前该页必须是已擦除状态。
• 擦以块为单位：擦除的最小单位是一个块，典型值由数百页组成（例如 256 页到 1024 页，对应几 MB 到十几 MB）。不能只擦一页。
• 不能原地改写：一个页写完之后，想改里面的内容，唯一办法是把整个块擦掉再写。这就是「异地更新（out-of-place update）」的物理根源。
• 擦写次数有限：每个块有 P/E 次数上限，SLC 量级数万次，MLC 数千到一万，TLC 数百到数千，QLC 更低；超过之后误码率快速上升，块被判废。
• 读本身也有副作用：反复读同一个块会干扰同块其它页（读干扰），需要计数并在阈值时把数据搬走重写。

把这些约束和主机语义并排放，冲突一目了然：主机想「改一个字节」，NAND 只能「换个地方写一整页，旧页留着，等攒够一整块的垃圾再一起擦」。

顺带解释一个常被追问的问题：擦除块为什么不能做小？因为擦除是靠在衬底与阱之间加高压、把整个块的浮栅（或电荷俘获层）里的电子一次性拉出来。块的物理边界由共享的阱与源线结构决定，做小意味着每个块都要配套一套高压选择管，面积开销会急剧上升。所以块做得大是电路结构权衡的结果，也正因如此，擦除一次的耗时在毫秒量级，远大于编程一页的几百微秒——这中间的差距，就是第 5 章里前台 GC 造成写延迟尖峰的物理根源。

1.3 翻译层的落点：谁来实现 FTL

「FTL 在哪」这个问题在不同产品形态上答案完全不同，做选型时这是第一个要问清楚的点，因为它直接决定主机端要承担多少工作。

对 SD NAND 与 eMMC 这类自带控制器的产品，主机工程师往往感觉不到 FTL 的存在，但盘的行为——写入掉速、寿命长短、掉电后数据是否完整——几乎全部由 FTL 决定。反过来，SPI NAND 这类裸颗粒方案把 FTL 完全交给主机，好处是透明可控、成本更低，代价是软件工作量与验证工作量都要自己承担。

这张表里的五个问题，建议在选型评审的第一轮就全部问完。它们共同决定了后面所有性能与寿命讨论的边界：FTL 在主机侧意味着写放大可以被自己控制，也意味着所有代价都要自己承担；FTL 在盘内则相反，可控性换成了集成度。

2.1 地址映射：LBA 到 PPN 的翻译

映射表是 FTL 的主索引结构。正向表的输入是逻辑页号 LPN（由 LBA 换算而来），输出是物理页号 PPN；反向表反过来，从 PPN 查回 LPN，主要用于 GC 搬移时找到「这个物理页属于哪个逻辑页」，以便更新映射。

映射表必须在掉电后能重建，所以它需要周期性地写回 NAND（checkpoint / journal），这本身就产生额外写入——只是这部分通常计入固件元数据写，在 WA 统计里可以单独列出来。

2.2 垃圾回收：把失效页变成可用块

一个块里只要还有一页是有效数据，就不能整块擦除。GC 的做法是：挑一个「垃圾比例最高」的块，把里面残余的有效页读出来，写到别的空闲块里，更新映射表，然后把原块整块擦除，还回空闲池。搬走的那些有效页，对主机而言没有任何意义——主机从未要求写它们——但它们实实在在消耗了 NAND 的写入带宽和 P/E 预算。

前台 GC 是「写入掉速」的直接原因：主机写请求到达时盘里已经没有现成的干净块，必须先现场完成一次搬移 + 擦除才能落盘，延迟立刻从几百微秒涨到几毫秒甚至更高。

GC 的另一个关键设计点是「选哪个块」。最朴素的做法是 greedy——挑垃圾最多的块，直觉上搬移量最小。但 greedy 有个已知缺陷：它会反复回收那些「写入密集但数据很快失效」的块，而把装着冷数据的高擦写次数块一直留着，长期看反而加速磨损不均。改进做法是成本收益策略（cost-benefit）：把块的「年龄」也计入成本，收益用「可释放空间 × 块已放置时间」来衡量，于是装着冷数据的老块即使垃圾比例不是最高，也可能被优先回收，从而把冷数据腾到别处、让磨损自然均衡。

2.3 磨损均衡：把擦写次数摊平

磨损均衡要解决的是「热点块先写穿」的问题。它分两类：

• 动态磨损均衡：每次分配新块时，优先挑擦写次数少的块。这只解决了「新写到哪」，不解决「老数据占着不动」。
• 静态磨损均衡：定期把长期不更新的冷数据从低擦写次数的块搬到高擦写次数的块，把低次数块腾出来给热数据用。这一步是纯额外写，会抬高 WA，但不做的话全盘寿命会被冷数据「锁死」。

工程上通常设一个阈值：当最大擦写次数与最小擦写次数之差超过某个值（典型值为几百到几千次，取决于器件 P/E 规格）时才启动静态均衡，避免过于频繁地搬冷数据。

一个实用的判断方法：如果业务里存在大片写入后基本不更新的数据（固件镜像、只读资源、历史归档），那么静态磨损均衡就是必须的，而且这部分额外写要在 WA 预算里单独留出来。反过来，如果数据几乎全部是热数据、全盘都在持续更新，静态均衡的触发频率会很低，它对 WA 的贡献可以忽略。

2.4 三个支撑模块：坏块管理、ECC、读干扰

表列之外还有第四个支撑模块——掉电保护：要解决的是掉电时映射表与缓存数据丢失，主要手段是元数据 journal 加掉电电容或安全写，失效后果是映射表损坏、整盘不可读，其 journal 写同样是额外写。

这四个模块加起来的共同特点是：它们的动作几乎都表现为「额外的 NAND 写入」。所以在做写放大预算时，不能只算 GC 的搬移，还要把静态均衡、读干扰刷新、元数据 checkpoint 这些一并计入，尤其是在小容量、低 OP 的嵌入式方案里，这几项的占比往往比想象中高。

3.1 块级映射：省表项，怕小写入

块级映射的表项是「逻辑块 → 物理块」，块内页偏移保持不变。表项数量等于块数，非常小：1 TB 裸容量按 16 MB 一块算，只有约 6.5 万项，4 B 一项也才 0.26 MB，完全可以放进控制器的 SRAM。

块级映射还有第二个好处：表的结构稳定、掉电重建快，因为表项少、变更频率低，元数据写也少。对 MCU 直接驱动 SPI NAND 这类资源紧张的方案，这两点往往比随机写性能更重要。

问题在于小写入。假设主机只改某个逻辑块里的 1 个页：由于页偏移固定，这个页不能直接写到新块的任意位置，必须把整个逻辑块的其它页也一起搬过去（读改写），然后擦掉旧块。一次 4 KB 的随机写，实际可能触发几 MB 的搬移，写放大直接飙到几十甚至上百倍。所以块级映射只适合写入模式高度顺序、或者容量很小的场景。

3.2 页级映射：最灵活，表也最大

页级映射的表项是「逻辑页 → 物理页」，任意逻辑页可以落到任意物理页。主机改一个页，就只写一个页，旧页标记失效——写入量与主机请求量严格 1:1，GC 之前的 WA 就是 1。这是大容量 SSD 的标准做法，也是第 6 章推导顺序写 WA约等于1 的前提。

代价是表项数等于页数。1 TB 裸容量、16 KB 页时约 6711 万项，4 B 一项需要 268 MB；如果页是 4 KB，表直接涨到 1 GB 量级。这也就是为什么大容量 SSD 必须配 DRAM，以及为什么「DRAM-less」方案要改用混合映射或把表放在主机内存（HMB）。

对 eMMC 与 SD NAND 这类成本敏感的器件，主流选择是最后两种：要么把表压缩到片内 SRAM 能装下的规模（靠混合映射或粗粒度表项），要么向主机借内存。选择哪种，取决于主机能否提供稳定的内存资源，以及产品对掉电重建时间的要求。

3.3 混合映射：log-block 与 superblock

混合映射的思路是「主体粗、局部细」：数据区按块级映射建表，另外划出一小部分块作为日志块（log block），按页级映射吸收随机写；日志块写满后再合并（merge）回数据块。合并分几种情形：

• 全顺序合并（switch merge）：日志块刚好被顺序写满，与数据块内容一一对应，直接把日志块变成新的数据块，旧块整块擦除，一次搬移都不用。
• 部分合并（partial merge）：日志块只有一部分页有效，需要搬走有效页再擦，产生搬移写。
• 完全合并（full merge）：日志块和数据块的有效页要合并到新块，搬移量最大，写放大也最高。

三种合并的代价差别很大，工程上的目标就是尽量让合并落在第一类：

• switch merge（最优）：日志块恰好被顺序写满，与数据块一一对应，直接互换角色，搬移量为零，只消耗一次擦除。
• partial merge（中等）：日志块只有一部分页有效，且位置恰好对齐，只需搬这一部分，再擦原块。
• full merge（最差）：日志块与数据块的有效页要一起搬到新块，搬移量等于两者的有效页之和，还要擦两个块。

这解释了为什么「顺序化写入」对混合映射方案的收益特别大：只要主机写入是顺序的，日志块就能被顺序写满，合并几乎总是落在第一类，写放大直接回到 1 附近；反之随机写会让 full merge 频繁出现，写放大迅速恶化。

superblock 是另一种常见做法：把多个物理块绑成一个逻辑大块统一管理（便于多通道并行与磨损均衡），内部仍按页映射。它在现代大容量 TLC / QLC 器件上几乎是标配，因为单块的页太多，一次性擦除与搬运的粒度过大。

3.4 映射表到底占多少 RAM

算式本身很简单，关键是选对三个输入：裸容量、页（或块）大小、每个表项的字节数。

映射表大小 = 表项数 × 每表项字节数
表项数（页级） = 裸容量 / 页大小
表项数（块级） = 裸容量 / 块大小
每表项 4 B（32 bit 即可寻址 4 G 个页，多数方案够用）

代入 1 TB 裸容量（按 1 TB = 1024^4 B 估算）：

• 页级，16 KB 页：1024^4 / 16384 约等于 6.71×10⁷ 项，× 4 B 约等于 268 MB。
• 页级，4 KB 页：1024^4 / 4096 约等于 2.68×10⁸ 项，× 4 B 约等于 1074 MB（超过 1 GB）。
• 块级，16 MB 块：1024^4 / 16×1024^2 约等于 6.55×10⁴ 项，× 4 B 约等于 0.26 MB。

工程上常用的一条经验法则是「每 1 GB NAND 配 1 MB 表内存」，即约 0.1% 的表开销，对应页级映射在 16 KB 页下的实际量级。对小容量的 SD NAND / eMMC，控制器片内 SRAM 通常只有几百 KB 到几 MB，这就反向决定了它只能走块级或混合映射，或者把部分表放到 NAND 上按需换入换出（代价是查表延迟与额外读）。

实践里这四种做法经常组合使用。判断标准不是「表能压到多小」，而是「在最坏随机读路径上，查表会不会成为瓶颈」——映射表省下来的内存，最终会以查表延迟和额外读的形式还回去一部分。

4.1 从 LBA 到物理页的五步链路

以一次 4 KB 的主机写为例（页大小按 16 KB 的典型值讨论时，控制器会先做读改写合并，逻辑相同）：

1. LBA 到达：主机通过 SD / eMMC / NVMe 接口下发写命令，携带起始 LBA 与数据。此时盘只知道逻辑地址。
2. 映射查询：FTL 用 LPN 查正向表。若该 LPN 已有映射，说明之前写过，本次是覆写；若无映射，是首次写。
3. 分配新页：从空闲块池取一个已擦除的干净物理页，把数据编程进去。覆写场景下的旧 PPN 暂时不动。
4. 旧页失效：把旧 PPN 在有效位图里标记为无效，它所占的物理页从此不属于任何 LPN，成为垃圾。
5. 更新映射：把 LPN 指向新的 PPN，并把映射变更写入元数据日志（journal），保证掉电后能恢复。

五步里只有第 3 步是主机真正要求的写入，第 5 步的元数据写是固件开销，第 4 步不写但埋下了 GC 的伏笔。所以主机写 1 页，盘里立即发生的写入是 1 页数据页 + 少量元数据页，写放大在这一刻还看不到，要等 GC 时才显现。

这里有一个对工程实践很有用的推论：把小写合并成大块写，收益不只是少写几次接口，更是让每次覆写产生的垃圾页在空间上聚拢。垃圾页聚拢，将来 GC 选中该块时的有效页占比 v 就低，搬移量就小。所以「合并写」这个动作在第 4 步就能看到收益，在第 5 章的 GC 里会再收获一次。

4.2 覆写为什么不是原地改

这是整个 FTL 存在的核心理由。主机把同一个 LBA 写了两遍，物理上发生的是：第一遍写在 PPN-A，第二遍写在 PPN-B，PPN-A 变成垃圾。LBA 没变，物理位置变了——这就是「异地更新」。

覆写还有一层容易被忽略的代价：读改写（Read-Modify-Write）。当主机下发的写入长度小于一个页、或者起止位置没有对齐到页边界时，控制器不能只写那一部分——页是编程的最小单位。它必须先把整页读出来，把要改的部分替换进去，再把整页写到新物理页。于是一次 512 B 的写入，实际产生了「读一整页 + 写一整页」两个动作，写入量被放大了页大小 / 请求大小倍。这正是第 11 章把「对齐写」列为主机侧第一优先手段的原因。

注意最后一行：文件系统删除文件这件事，NAND 是完全不知道的。被删文件占用的那些物理页，在 FTL 眼里依然是「有效数据」，GC 遇到它们还得老老实实搬一遍。这正是第 8 章 TRIM 要解决的问题。

4.3 映射表的一致性与掉电风险

映射表本身也是数据，也要存在 NAND 上。这里有一个绕不开的矛盾：每写一次数据页就要更新一次映射，如果每次都同步落盘，元数据写会爆炸；如果不落盘，掉电时映射表可能丢失。

还有一个实践中的细节：元数据写的大小虽然只有几十到几百字节，但它不能单独写一页——同样要占一个物理页（或者与其他元数据合并后占一页）。所以「攒够一批再提交」几乎是所有方案的标配动作，区别只在攒多少。攒得多，掉电窗口大、元数据写少；攒得少，掉电丢失少、元数据写多。这个权衡点应该和掉电保护能力一起决定：有掉电电容的方案可以放心攒，没有的方案要把窗口压小。