2. FTL地址映射机制：逻辑地址到物理地址的映射
好，咱们直接进入正题。FTL（Flash Translation Layer）最核心的活儿是什么？说白了就一件事：把主机发过来的逻辑地址，翻译成NAND Flash上真实的物理地址。你想想看，主机以为自己在读写一块普通的磁盘，实际上底层是块擦写次数有限、需要先擦后写的闪存。这个「翻译官」就是FTL的地址映射机制。
我个人习惯把地址映射比作「字典翻译」。主机说「我要读第100页」，FTL查一下字典，发现第100页其实存在第500页的位置，那就去第500页读数据。这个字典，就是映射表。
2.1 逻辑地址到物理地址的映射
映射的基本单位是什么？这取决于你的FTL设计粒度。主机发来的LBA（Logical Block Address）通常是512字节或4KB的扇区。但NAND Flash的最小读写单位是页（Page），最小擦除单位是块（Block）。
所以映射过程大致是这样的：
- 第一步：把LBA转换成逻辑页号（LPN）。比如一个页是16KB，那LBA 0~31就对应LPN 0。
- 第二步：查映射表，找到LPN对应的物理页号（PPN）。
- 第三步：根据PPN去NAND里读写数据。
嗯，这里要注意：映射表里存的不是简单的「一对一」关系。因为闪存有写前擦除的特性，你更新一个逻辑页的数据，不能直接覆盖原来的物理页，得写到另一个空闲页里，然后更新映射关系。这就是所谓的「异地更新」（Out-of-Place Update）。
核心要点：地址映射的本质是「间接寻址」。没有这层间接，FTL就玩不转垃圾回收、磨损均衡这些高级功能。
2.2 映射表结构：三种主流方案
映射表怎么组织？这直接决定了你的FTL性能、内存开销和写放大系数。我做过好几个项目，踩过不少坑，下面这三种方案我都亲手调过。
2.2.1 页级映射（Page-Level Mapping）
这是最灵活、性能最好的方案。每个逻辑页都对应一个物理页，映射表里存的是LPN→PPN的对应关系。
优点：
- 写性能极佳。每次写操作只需要分配一个新物理页，更新映射项即可。
- 垃圾回收效率高。有效页迁移时，只需要更新映射表，不需要搬动数据。
缺点：
- 映射表太大！假设一个512GB的SSD，页大小16KB，那就有32M个逻辑页。每个映射项4字节，光映射表就要128MB。DRAM成本扛不住。
我在项目中遇到过这种情况：一个消费级SSD主控，内置SRAM只有256KB，根本塞不下页级映射表。怎么办？只能上缓存策略，或者换方案。
2.2.2 块级映射（Block-Level Mapping）
映射粒度从页提升到块。每个逻辑块（包含多个页）映射到一个物理块。块内的页偏移是固定的。
优点：
- 映射表极小。块数量比页少两个数量级，映射表内存开销降低99%。
缺点：
- 写性能灾难。你更新块里的一个页，得把整个块读出来，修改，再擦除整个块，写回去。这就是典型的「读-改-写」惩罚。
- 写放大系数极高。更新4KB数据，可能要搬整个块（比如2MB），写放大500倍。
避坑指南：我曾经在一个低功耗IoT项目里用了纯块级映射，结果写放大太严重，闪存寿命三个月就耗尽了。后来我学乖了——块级映射只适合顺序写入的场景，随机写入千万别用。
2.2.3 混合映射（Hybrid Mapping）
这是工业界最常用的方案。它把物理块分成两类：
- 数据块（Data Block）：采用块级映射，存放冷数据。
- 日志块（Log Block）：采用页级映射，存放热数据（频繁更新的数据）。
写操作先写到日志块里，等日志块写满了，再通过「合并操作」（Merge）把数据刷回数据块。
合并操作有三种：
- 全合并（Full Merge）：把日志块和数据块合并成一个新数据块。开销最大。
- 部分合并（Partial Merge）：日志块里的数据刚好填满数据块的空闲页，直接合并。
- 交换合并（Switch Merge）：日志块里的数据覆盖了整个数据块，直接交换角色。开销最小。
我建议你在设计混合映射时，重点关注日志块的数量和合并策略。日志块太少，频繁合并，性能下降；日志块太多，映射表又大了。这个平衡点需要根据实际负载来调。
| 映射方案 | 映射表大小 | 随机写性能 | 写放大 | 适用场景 |
|---|---|---|---|---|
| 页级映射 | 大（~128MB/512GB） | 优秀 | 低（1.0~1.5） | 高性能SSD |
| 块级映射 | 小（~512KB/512GB） | 极差 | 高（10~500） | 顺序写入设备 |
| 混合映射 | 中（~4MB/512GB） | 良好 | 中（2~5） | 消费级SSD、U盘 |
2.3 映射表存储与缓存策略
映射表放哪儿？这是个经典问题。DRAM里放不下全部，NAND里存取又太慢。所以实际方案都是「分级存储 + 智能缓存」。
2.3.1 存储架构
典型的映射表存储分三级：
- SRAM缓存：存放最热门的映射项。容量小（几十KB），速度极快（几个周期）。
- DRAM缓存：存放近期访问过的映射项。容量大（几MB到几百MB），速度较快（几十纳秒）。
- NAND闪存：存放完整的映射表。容量巨大，但读取一次要几十微秒。
系统上电时，从NAND里把映射表加载到DRAM。运行过程中，DRAM里的映射表不断更新，并定期刷回NAND。突然掉电怎么办？那就需要「映射表日志」来恢复。
经验之谈：我做过一个掉电保护方案，每次写操作先写映射表日志到NAND的一个专用区域，再写数据。这样即使掉电，上电后也能通过日志重建映射表。代价是每次写操作多了一次NAND写入，性能下降约5%。
2.3.2 缓存替换策略
DRAM缓存满了，要踢掉哪些映射项？常见的策略有：
- LRU（最近最少使用）：踢掉最久没被访问的。实现简单，但对扫描型负载不友好。
- LFU（最不经常使用）：踢掉访问次数最少的。能抗扫描，但实现复杂。
- ARC（自适应替换缓存）：结合LRU和LFU的优点，动态调整。IBM发明的，效果很好。
我个人习惯用LRU的变种——Segmented LRU。把缓存分成两个队列：一个放热数据，一个放冷数据。新数据先进冷队列，被再次访问才升到热队列。这样能有效防止扫描污染。
2.3.3 预取策略
缓存命中率不够？那就预取。当访问一个映射项时，把相邻的几个映射项也一起加载到缓存。因为地址访问通常有空间局部性——你读了第100页，很可能接下来要读第101页。
预取粒度要小心。预取太多，浪费带宽和缓存空间；预取太少，命中率提升不明显。我一般设预取窗口为4~8个映射项，然后根据实际命中率动态调整。
总结一下：映射表的设计是FTL的灵魂。页级映射性能好但内存开销大，块级映射省内存但性能差，混合映射是折中方案。缓存策略决定了映射表的访问效率，好的缓存设计能让90%以上的映射访问命中DRAM。
我的建议：如果你是新手，先从混合映射入手。它足够应对大部分场景，而且实现复杂度适中。等你对FTL有了深入理解，再考虑针对特定负载优化映射策略。