上一篇《SSD科普二十九》中，我们介绍了一条 Write Command 是如何从 Host 到达 SSD。

但是，对于 SSD 来说：

收到 Write Command，并不代表数据已经真正写入 NAND。

Host 只是告诉 SSD：

我要写入这些数据。

而 SSD 内部还需要解决：

• 数据应该暂存在哪里？
• 这些数据应该写入 NAND 的什么位置？
• 如何利用 NAND 内部资源提高写入效率？
• 写入完成后，如何保证以后还能找到这些数据？

这一整套过程，就是 SSD 的 Write Path（写入路径）。

一、Write Command 到达 SSD 后

当 SSD Controller 收到 Host 的写请求后，首先需要接收数据。

简单来看，一次写入大致会经历以下几个阶段：

Host Write Request
Host 发起写请求，告诉 SSD 需要修改哪些逻辑地址的数据。
↓
SSD Controller
Controller 接收来自 Host 的数据，并开始协调内部处理流程。
↓
Write Buffer
数据进入 SSD 内部缓存区域，等待后续处理。
↓
FTL 处理
FTL 根据当前 NAND 状态，对这次写入进行地址规划。
↓
NAND 写入
最终由 NAND Flash 完成真正的数据存储。

这里的流程是为了方便理解。

真实 SSD Firmware 内部，并不是简单按照一条直线执行。

不同阶段之间会相互交叠，多个请求也可能同时处于不同处理阶段。

后面会讲到这一点。

二、数据为什么需要经过 Buffer？

数据进入 SSD 后，并不会直接发送给 NAND。

原因是：

Host 和 NAND 是两个工作节奏不同的系统。

Host 可以持续发送写请求。
但是 NAND 完成一次 Program 操作，需要一定时间。

如果每收到一笔数据，都必须等待 NAND 完成，那么 Host 的速度就会受到 NAND 处理节奏限制。

因此 SSD Controller 需要一个中间缓冲区域，它的作用并不是简单“存一下数据”。

更重要的是：

让 Host 写入和 NAND 内部操作可以解耦。

例如：

Host 连续发送：

Write A
↓
Write B
↓
Write C

SSD 不一定立即对应执行三次 NAND 写入。

而是可以根据内部策略，对这些数据进行组织，然后安排后续写入。

这样可以提高 NAND 资源利用率。

三、FTL开始规划这次写入

数据进入 SSD 后，接下来就是 FTL 参与。

上一篇以及之前的文章中，我们已经介绍过：

Host 看到的是逻辑地址：

LBA（Logical Block Address）

而 NAND 内部使用的是物理位置：

Channel、Die、Plane、Block、Page

FTL 的作用，就是连接这两个世界。

一次 Write 请求进入 FTL 后，主要完成几个事情。

1. 找到可以写入的位置

由于 NAND Flash 不能像传统存储一样直接覆盖已有数据。

所以 SSD 的写入方式通常是：

找到新的空间写入，然后更新映射关系。

例如：

原来的数据
LBA 1000
↓
Block 10 Page 5

↓

新的数据
LBA 1000
↓
Block 200 Page 30

新的数据写入成功后：

FTL 再更新：

LBA 1000 现在对应新的物理位置。

这也是 SSD 可以实现随机写入的基础。

2. 生成内部写入任务

Host 发来的请求，本质上只是：

我要修改某个逻辑地址的数据。

但是 NAND 并不知道什么是 LBA。

所以 FTL 需要把：

“写入 LBA 1000”

转换成：

“向某个 NAND 物理位置执行写入操作”。

也就是说：

FTL负责完成：

逻辑请求 → 物理写入任务

四、从 FTL 到 NAND

完成地址规划以后，数据才进入真正的 Flash 写入阶段。

简单来看：

FTL 生成写入任务
FTL 根据逻辑地址和当前资源状态，确定后续写入方向。
↓
Flash 管理部分协调
根据 NAND 当前状态，协调不同 Flash 资源。
↓
NAND Interface 发送命令
Controller 通过接口向 NAND 发起操作。
↓
NAND 执行 Program
NAND 完成真正的数据写入。

这里需要说明：

为了方便理解，我们把 FTL 和 NAND 管理分开描述。

但在真实 SSD Firmware 中：

地址管理、空间管理、NAND 调度之间通常是相互配合的，并不是完全独立的几个模块。

SSD 的性能也不仅仅来自 NAND 本身，单颗 NAND 的 Program 能力有限，SSD 会利用多个 NAND 资源：

• 多 Channel
• 多 Die
• 多 Plane

让多个操作尽可能并行执行。

因此SSD Controller 如何组织 NAND 资源，也是影响性能的重要因素。

五、Write Path 并不是一条串行流程

前面的流程看起来像：

Buffer
↓
FTL
↓
NAND

好像必须做完第一步，才能开始第二步。

但真实 SSD 并不是这样工作的。

SSD Controller 通常会同时处理多个请求。

例如：

Write A
Buffer 阶段
↓
FTL 阶段
↓
NAND 阶段

与此同时：

Write B
可能已经进入 Buffer 或 FTL 阶段。

同时：

Write C
可能正在等待后续处理。

当第一笔数据正在 NAND Program 时：

第二笔数据可能已经进入 Buffer。

第三笔数据可能正在等待 FTL 处理。

这就是 SSD 能够获得高性能的重要原因：

不同阶段重叠执行，形成流水线。

SSD 的性能提升，并不仅仅依靠 NAND 本身速度提升，也依赖 Controller 对多个阶段的协调能力。

六、什么时候算一次 Write 完成？

这里有一个容易误解的问题。

很多人认为：

SSD 只有等 NAND Program 完成以后，才会告诉 Host 写成功。

但实际上：

Write Completion 的时机，和 SSD 设计有关。

例如：

如果 SSD 具备掉电保护能力（PLP）。

那么数据进入受保护缓存以后：

即使还没有完成最终 NAND 写入，也可以安全返回 Host。

流程可能类似：

Host Write
↓
进入受保护缓存
↓
返回完成状态
↓
后台完成 NAND 写入

而没有掉电保护的设计，则需要更加谨慎。

所以：

Host 收到 Write Completion，并不一定代表 NAND 已经完成 Program。

这也是为什么不同 SSD 在写延迟、缓存策略以及掉电保护方面会存在差异。

七、一条 Write Path 总结

把整个过程串起来：

Host Write Command
Host 提交写请求。
↓
SSD Controller 接收数据
Controller 开始处理请求。
↓
Write Buffer 缓存
暂存数据，缓冲 Host 与 NAND 之间的差异。
↓
FTL 完成地址规划
完成逻辑地址到物理位置的规划。
↓
生成 NAND 写入任务
将 Host 请求转换为 Flash 可以执行的操作。
↓
Flash 资源调度
协调不同 NAND 资源。
↓
NAND Program
数据真正写入 Flash。
↓
更新映射关系
保存新的逻辑地址对应关系。
↓
完成状态返回
向 Host 报告写入结果。

从 Host 角度看：一次写入只是提交了一条命令。

但是在 SSD 内部，它需要经过：

• 数据接收
• 空间管理
• 地址转换
• NAND 资源协调
• 状态维护

多个阶段。

这也是 SSD Firmware 存在的意义：

让原本只能按照 NAND 规则工作的 Flash，变成一个高性能、可靠的存储设备。

总览图如下：

谢谢你读我的文章