4. Flash转换层(FTL)：逻辑地址到物理地址映射、垃圾回收、磨损均衡的核心机制
好，咱们今天聊聊FTL。说实话，这是整个Flash存储系统里最核心、也最容易被忽视的一层。你想想看，上层应用读写文件时，根本不知道底下是NAND Flash还是机械盘。这个「不知道」的功劳，就是FTL的。
FTL的全称是Flash Translation Layer，翻译过来叫闪存转换层。它的任务说白了就一个：把上层发来的逻辑地址，翻译成Flash芯片里真实的物理地址。但这事儿远没听起来那么简单。
4.1 逻辑地址到物理地址的映射
我刚开始接触FTL时，觉得这不就是个查表嘛。后来踩了坑才发现，这个「表」怎么设计，直接决定了性能、寿命和掉电安全。
4.1.1 为什么需要映射？
NAND Flash有个很烦人的特性：不能原地覆盖写。你写了一个页，想改里面的数据？不行，必须先擦除整个块，再写。但擦除操作很慢，而且会磨损芯片。
所以FTL的做法是：写新数据时，找个空闲页写进去，然后把原来的页标记为无效。这样一来，逻辑地址A对应的物理地址就变了。映射表就是记录这个对应关系的。
核心概念：逻辑地址是上层看到的「假地址」，物理地址是Flash芯片上真实的「真地址」。FTL就是那个「翻译官」。
4.1.2 映射粒度：页级 vs 块级
映射粒度直接影响性能和内存开销。我见过不少项目在这上面栽跟头。
| 映射方式 | 粒度 | 内存占用 | 写放大 | 典型场景 |
|---|---|---|---|---|
| 页级映射 | 4KB（一个页） | 高（每页一个条目） | 低 | 高性能SSD |
| 块级映射 | 512KB（一个块） | 低（每块一个条目） | 高 | 低端存储卡 |
| 混合映射 | 块级+页级缓存 | 中等 | 中等 | 主流eMMC/UFS |
我个人习惯在嵌入式项目里用混合映射。为什么呢？因为页级映射虽然性能好，但4KB的映射表条目需要4字节，一个128GB的Flash光映射表就要128MB内存——很多MCU根本扛不住。
我的经验：在资源受限的IoT设备上，我建议用块级映射+写缓存。虽然写放大高一些，但内存占用能控制在几十KB以内。我曾经在一个RTOS项目里，硬是把FTL映射表压缩到了16KB，跑了一年多没出问题。
4.2 垃圾回收（Garbage Collection）
垃圾回收，简称GC。这是FTL里最耗时的操作，也是性能瓶颈的重灾区。
4.2.1 为什么需要GC？
你想想看，每次写新数据，FTL都找个新页写，旧页标记为无效。时间一长，整个Flash里到处都是「无效页」。但空闲页越来越少，直到某天写不下去了。
这时候GC就登场了：挑一个包含无效页的块，把里面还有效的数据搬走，然后擦除整个块，变成空闲块。
4.2.2 GC的触发时机
GC不是随时都在跑的。触发太频繁，影响性能；触发太晚，写入会卡死。我见过一个产品，就是因为GC策略太激进，导致写入延迟从1ms飙到200ms。
- 空闲块低于阈值：比如空闲块少于总块数的10%，立即触发GC
- 写入请求等待：没有空闲页可用时，先做GC再服务写入
- 后台空闲时：系统空闲时偷偷做GC，这叫「后台GC」
避坑指南：我曾经在一个视频监控项目里，因为后台GC没做好，导致录像写入时突然卡顿几秒钟。后来改成「写入时只做紧急GC，空闲时做深度GC」，问题才解决。
4.2.3 GC的代价：写放大
写放大（Write Amplification）是GC带来的副作用。你本来只想写4KB数据，但GC为了腾出空间，可能搬走了128KB的有效数据。实际写入量是用户请求的几十倍。
写放大系数 = 实际写入Flash的数据量 / 上层请求写入的数据量
这个系数越小越好。理想情况是1.0，但实际能做到2.0~3.0就算不错了。
4.3 磨损均衡（Wear Leveling）
磨损均衡，说白了就是让Flash里每个块被擦除的次数尽量平均。NAND Flash的擦除寿命是有限的——SLC约10万次，MLC约1万次，TLC约3000次。如果某些块被频繁擦除，它们会先「挂掉」，整个设备就废了。
4.3.1 动态磨损均衡
动态磨损均衡只在写入时做。每次要选一个空闲块来写，FTL会优先选擦除次数少的块。这样冷数据块（很少被更新的数据）的擦除次数就低，热数据块（频繁更新的数据）的擦除次数就高。
但问题来了：如果某个块存的是只读数据（比如系统镜像），它永远不会被擦除。动态均衡对它无效。
4.3.2 静态磨损均衡
静态磨损均衡就是为了解决上面那个问题。它会主动把冷数据搬走，让那些擦除次数低的块也能被用上。
具体做法是：FTL定期扫描所有块，找到擦除次数最低的块，把里面的数据搬到另一个块，然后把这个「低擦除次数」的块释放出来给热数据用。
关键点：静态磨损均衡会引入额外的数据搬移，增加写放大。但为了延长Flash寿命，这笔账是划算的。我一般在产品设计时，会设定一个阈值：当最大擦除次数和最小擦除次数的差值超过某个值（比如500次），就触发静态均衡。
4.4 FTL的整体架构
下面这张图是我自己画的FTL核心流程，你看一眼就能明白整体逻辑。
4.5 实际项目中的FTL调优
讲完理论，咱们聊聊实战。我在几个产品里总结了一些经验，分享给你。
4.5.1 减少写放大的技巧
- 对齐写入：上层写入的数据大小尽量是页大小的整数倍。比如页大小4KB，你就一次写4KB、8KB，别写3KB。不对齐的写入会触发读-改-写，写放大直接翻倍。
- 批量提交：把多个小写入合并成一个大写入。我做过测试，4KB随机写入的写放大是8.0，但合并成64KB顺序写入后，写放大降到了1.5。
- 预留空间（OP）：Flash总容量里留一部分不映射给用户，专门给GC用。OP越大，GC越轻松，写放大越小。一般留7%~28%。
4.5.2 掉电保护
血的教训：我曾经有一个产品，FTL的映射表只存在内存里，没有定期刷到Flash。结果一次掉电，映射表全丢了，整个文件系统变成了一堆乱码。从那以后，我所有项目都加了掉电保护。
掉电保护的核心是：映射表必须持久化。常用的做法有：
- 写时复制（Copy-on-Write）：每次更新映射表，都写到一个新位置，保证任何时候都有一个完整版本
- 日志结构（Journaling）：把映射表的变更记录到日志区，重启时回放
- 电池备份：高端SSD会用超级电容，掉电后还能坚持写完最后一批数据
4.5.3 性能调优参数
下面这个表格是我常用的FTL参数配置，你可以参考一下。
| 参数 | 推荐值 | 说明 |
|---|---|---|
| GC触发阈值 | 空闲块 < 15% | 太低容易写卡顿，太高浪费空间 |
| GC搬移块数 | 每次2~4个块 | 一次搬太多会卡住写入 |
| 静态均衡阈值 | 擦除次数差 > 500 | 根据Flash寿命调整 |
| 映射表刷盘间隔 | 每100次写入或每30秒 | 平衡安全性和性能 |
| 预留空间(OP) | 12.5% (1/8) | 消费级常用，企业级更高 |
我的建议：别一上来就追求极致性能。先跑个压力测试，看看写放大系数和GC频率。如果写放大超过5.0，或者GC触发太频繁，再逐步调整参数。我一般会留一周时间专门做FTL调优，急不得。
好了，FTL的核心机制就聊到这儿。记住三个关键词：映射、GC、磨损均衡。这三者互相影响，牵一发而动全身。做产品时，一定要把它们放在一起考虑，别拆开看。