1 SSD 内部要理解什么
把服务器断电后，内存中的临时结果通常会消失，SSD 中已经可靠持久化的数据则应保留。SSD 是使用非易失性存储介质的固态存储设备。它没有机械硬盘的磁头和旋转盘片，但这不意味着任意地址的读写成本都相同。闪存的修改约束、控制器的后台整理，以及设备当时剩余的空闲空间，会共同改变请求完成的时间。
从实物看，M.2 SSD 常是一块狭长电路板，上面有控制器和若干 NAND 闪存封装，部分型号还配有独立 DRAM。2.5 英寸 SSD 把类似部件放进外壳；服务器也可能使用 U.2 等形态。封装里可以堆叠多个闪存裸片。外观上看到的黑色芯片数量，既不直接等于内部并行度，也不能单独决定容量和耐用性。
控制器负责接收主机请求、分配物理位置、纠错和管理介质。NAND 保存用户数据和设备需要的管理信息。独立 DRAM 可以缓存地址映射等信息，但不是所有 SSD 都有这种配置。还有设备会在特定条件下借用主机内存保存部分管理数据；这与把所有写入安全地留在断电后仍可恢复的介质中，是不同的问题。
沿服务器的数据路径观察，CPU 执行程序，内存暂存待写内容，操作系统把块请求送给存储设备。若数据来自远端，还要先经过网卡和网络。主机通常用逻辑块地址描述读写位置，不需要知道某段内容落在第几个闪存块。设备把逻辑地址变成实际闪存位置，这层转换正是理解 SSD 的入口。
总线也不能与介质混为一谈。例如，SATA 6 Gb/s 描述链路能力，PCIe 4.0 x4 描述代际与通道数，NVMe 描述一类访问协议。接口能够传得快，不保证 NAND 可以无限期以同样速度接受新数据。同样采用 PCIe 4.0 x4 的 2 块 SSD，也可能因为容量、闪存类型、固件和散热条件不同，在长期写入时表现悬殊。
本课要建立的判断是：每次逻辑写入都要消耗设备内部资源，而这些消耗并不总在当次请求里显现。我们重点理解页、块、地址映射、垃圾回收和写放大，随后把它们连到耐用性与尾延迟。纠错编码的具体算法、闪存电压分布和控制器调度细节留待进阶学习；当前只需知道它们存在，并会影响设备的可靠性和耗时。
2 闪存页、块与擦除约束
NAND 闪存不能像普通内存一样，随意把原位置的新旧内容直接覆盖。入门时先记住 2 个单位：页是读取和编程的重要单位，块是擦除的单位，1 个块包含许多页。编程是把数据写入闪存单元的操作。实际器件还有更细的组织与操作限制，这里暂用完整页模型理解主要成本，不把教学示例当作所有设备的真实几何结构。
假设某颗闪存的页大小为 16 KiB，每块有 256 页，那么每块容量就是 4 MiB。主机即便只修改 4 KiB 数据，也不能据此推断设备只做 4 KiB 的物理操作。控制器可能先合并多个小写入，也可能需要结合旧数据组织新页。主机请求大小、文件系统块大小、闪存页大小处在不同层次，恰好相等并不是正常工作的前提。
为什么不在原位置擦完再写？因为擦除会作用于整个块。若块内只有少量数据需要更新，其他页仍然有效，直接擦除会把它们一起清掉。更常见的路径是把新内容写到别处的可用页，再把逻辑地址指向新位置。旧位置成为无效页；其中的内容可能仍物理存在，但正常读取这个逻辑地址时已经不会选择它。
可以把页的状态分为可写、有效和无效。可写页还没有被这轮编程使用；有效页保存当前需要保留的数据；无效页保存已经被替代或不再需要的数据。无效页不等于立刻可写，必须等它所在的块被整体擦除后，才能重新进入可用空间。这是 SSD 内部空间管理与普通“删掉就能用”的直觉之间的关键差别。
例如，逻辑地址 L7 的旧内容在块 A 的某页，新内容写入块 B 后，映射表改指块 B。此时块 A 可能还有 200 个有效页，不能为了回收 L7 的旧页就直接擦除 A。控制器需要等候合适时机，把仍有效的内容搬走，再擦除块 A。更新越分散，越容易在许多块里留下少量无效页，回收时就越可能需要搬运大量有效内容。
文件删除还隔着操作系统。删除文件通常先改变文件系统元数据，设备未必马上知道原来的逻辑地址已不再使用。TRIM 或同类取消分配通知可以把这个信息传下去，使控制器以后无需继续保留这些内容。通知并不承诺立刻擦除物理页，也不等于安全擦除；如果虚拟磁盘、卷管理或其他中间层不传递通知，设备看到的有效数据范围还可能大于应用以为的范围。
读操作通常不需要先擦除，所以读写不对称是很自然的结果。但读也不是完全独立的：它可能等待共享通道，或者碰上写入、擦除与纠错重试。理解这种不对称，才能解释为什么“只是改了几个字节”有时引出一连串后台动作，也才能避免把每次延迟波动都归咎于 CPU 或网络。
3 FTL、垃圾回收与写放大
FTL 是闪存转换层，负责把主机看到的逻辑地址映射到闪存中的物理位置。主机重写同一个地址时，地址本身可以保持不变，背后的物理页却已经更换。映射表可能放在 DRAM、闪存以及其他缓存结构中，不同产品实现不同。对入门者而言，重点是“主机地址稳定，物理位置可移动”，而不是背出某种映射表组织方式。
映射更新也必须可恢复。设备不能只保存新数据，却在断电后丢失找到新数据的线索；也不能让主机相信某次写入已经持久化，恢复后却仍指向旧内容。控制器会为管理信息设计相应的记录与恢复机制。至于主机收到什么完成信号、缓存何时必须落到非易失介质，还与命令语义、系统配置和断电保护能力有关，不能只凭“写调用返回了”作结论。
当可用页逐渐减少，控制器需要垃圾回收，也就是挑选待整理的块，把有效页复制到其他位置，然后擦除旧块。回收获得的是整块可写空间，付出的代价则包括读取有效页、重新编程这些页以及擦除。无效页比例越高，通常越容易以较少搬运换回空间；不过实际选择还要顾及磨损分布、并行资源和设备策略。
用 8 页的小块做例子。若待回收块中有 2 页有效、6 页无效，先搬走 2 页，再擦除旧块，会释放 8 页可写空间。但搬运在别处消耗了 2 页，因此净增加的可用容量是 6 页。若块内还有 7 页有效，净增加的空间就只有 1 页。同样是“擦了 1 个块”，为获得相同可用容量所做的复制工作可能相差很大。
写放大用来表达这种额外成本。常见的介质写放大系数 WAF，等于某段时间内 NAND 实际写入字节数除以主机写入字节数。假设主机写入 100 GB，设备内部共编程 250 GB，则 WAF 为 2.5。分子包含哪些内部写入，要看设备计数器的定义；如果只有主机写入计数，就不能据此直接测出 WAF。
这里的主机写入指到达设备接口的写入，并不总等于应用有效载荷。应用保存 1 GB 数据，文件系统日志、数据库日志和重写过程可能先使设备收到 1.4 GB；介质内部若又放大 2 倍，NAND 写入可能达到 2.8 GB。讨论写放大时必须说清分子和分母所在层次，否则应用团队与硬件团队可能在使用同一个词，却讨论不同的问题。
顺序写更容易形成集中失效、便于整体回收的数据区域；分散的小随机更新则可能把无效页撒进很多块。不过顺序写不保证 WAF 永远接近 1，随机写也没有固定系数。设备已写入多少、哪些数据长期不变、是否传递释放通知、后台是否有整理时间，都会改变结果。把 WAF 当作随负载与状态变化的观测量，比当作某型号的恒定参数更有用。
垃圾回收还不等于磨损均衡。前者主要解决可写空间回收，后者主要避免少数块过早耗尽擦写寿命。磨损均衡有时也会搬动长期不变的数据，从而产生额外写入。入门阶段只需分清目的：设备既要腾出空间继续写，也要让介质消耗保持在可管理的范围内，这些管理工作都需要带宽和时间。
4 动手：对照顺序写与随机写的成本
这个实验要比较相同请求大小下，不同访问位置模式的表现。选择独立、可丢弃的测试盘最容易解释结果；若只能使用现有机器上的文件，也应选择明确允许测试的文件系统，并确认至少有 8 GiB 空间余量。写测试会产生真实介质写入，也可能影响同盘服务。下面只针对新建临时目录中的普通文件，不能把设备节点填进文件名参数。
先记下环境：设备容量和固件版本、SATA 或 PCIe 链路、文件系统、剩余空间、温度、是否经过虚拟化，以及是否有其他进程使用同盘。工具选择 fio，运行前用其版本信息确认已安装。示例使用同步引擎、1 个任务、队列深度 1 和 4 KiB 请求，让访问模式成为主要比较变量。高队列深度会增加并行，也会引入更多排队，适合在后续单独研究。
TEST_DIR=$(mktemp -d /path/to/test-volume/h28-ssd.XXXXXX)
fio --name=prepare --filename="$TEST_DIR/sample.bin" \
--size=4G --rw=write --bs=1M --ioengine=psync \
--iodepth=1 --numjobs=1 --direct=1 --end_fsync=1
fio --name=seq4k --filename="$TEST_DIR/sample.bin" \
--size=4G --rw=write --bs=4k --ioengine=psync \
--iodepth=1 --numjobs=1 --direct=1 --time_based=1 \
--runtime=60 --ramp_time=10 --end_fsync=1 --group_reporting=1
fio --name=rand4k --filename="$TEST_DIR/sample.bin" \
--size=4G --rw=randwrite --bs=4k --ioengine=psync \
--iodepth=1 --numjobs=1 --direct=1 --time_based=1 \
--runtime=60 --ramp_time=10 --end_fsync=1 --group_reporting=1把占位路径替换成测试卷中的实际目录，保留同一个终端中的 TEST_DIR 变量。准备阶段用较大请求把文件完整写过，使后续主要比较覆盖写，减少首次分配文件空间的干扰。direct=1 尽量绕过操作系统页缓存，但不代表绕过设备缓存，也不代表每次请求完成都经过单独的持久化确认。若文件系统不支持这种直接 I/O，应记录限制并调整实验方案。
对每轮记录带宽、IOPS、完成延迟的平均值、P99 和 P99.9，并观察运行期间的温度与主机写入计数。4 KiB 请求达到 100000 IOPS 时，对应约 390.6 MiB/s；这一换算能检查报告是否混淆了请求数量和字节数量。队列深度 1 的结果不代表设备最大能力，它描述的是当前负载条件下的响应和吞吐。
按这个顺序跑完后，随机写继承了顺序写结束时的设备状态，所以不能立即把差异全算在访问模式上。可以在记录清楚的相同起始条件下交换测试顺序，或在专用盘上设计更完整的预处理。不要为追求“重置”而清空生产盘。4 GiB 范围与约 60 秒的测量通常只能展示局部现象，不能证明整盘稳态，也未必能耗尽动态写缓存。
若设备公开介质写入统计，可以在固定测量窗口前后采样，按相同单位求增量，再与主机写入增量求比。应纳入约定的收尾观察窗口，因为数据搬运可能继续发生；同时排除其他写入者。只有通用主机写入计数时，就把结论写成“随机写的延迟更高”或“吞吐下降”，不要把缺失的介质数据补成一个猜测的 WAF。
5 耐用性、预留空间与稳态性能
NAND 的擦写次数有限，SSD 因而需要管理介质寿命。产品资料中常见 TBW，表示规定条件下的累计写入耐用性指标；也常见 DWPD，表示在给定年限内，每天可写相当于多少个标称容量。它们必须和容量、期限、工作负载及保修条款一起读。达到某个标称值不代表下一次写入必然失败，未达到也不意味着设备绝无其他故障。
例如，标称容量 1 TB、期限 5 年、指标 1 DWPD，按每年 365 天粗算，对应约 1825 TB 的主机写入量。若系统每天实际向设备写 0.5 TB，线性外推的写入预算约可覆盖 10 年，但这不是设备寿命承诺：保修期限、温度、断电、控制器损坏和数据保留要求仍然独立存在。选型时要以具体资料的单位和条件为准。
把业务写量折算成主机写量是必要步骤。每天新增 100 GB 的记录，若日志、索引维护和后台合并让设备实际接收 400 GB，就应按后者与主机侧 TBW 比较。TBW 通常已经是对外给出的主机写入口径，不能再无条件乘上自己猜测的 WAF。只有建立内部介质消耗模型时，才需要把介质放大明确放进计算，并说明模型条件。
预留空间给控制器留下搬运和回收的余地。设备出厂时可能已经隐藏了部分物理容量，这部分不出现在主机可寻址容量里。运维还可以通过受支持的配置方式减少可用范围，或让文件系统保持足够空闲并正确传递释放通知。它们实现方式不同；单纯把某个已写满分区卸载、或者删除分区表，不保证设备立即知道哪些旧数据已经无效。
可用余量通常有利于减少回收压力，但没有适用于所有设备的固定最佳百分比。空闲空间比例相同，热数据不断更新与大量冷数据长期不变，也会形成不同的回收条件。容量更大的型号还可能拥有更多内部并行资源，所以“同系列按容量等比例缩小性能”也未必成立。实际要通过目标负载下的测量确定容量余量和性能余量。
稳态性能指设备经过足够负载后，在给定条件下表现进入相对稳定的统计范围。它不是要求每秒数值完全相同。新盘、刚释放大量空间的盘，可能先表现很好，随后因缓存耗尽与回收压力下降。测试应预先约定窗口和稳定判据，例如连续若干个等长窗口的吞吐与延迟分布变化都在项目接受范围内，同时检查温度、占用率和后台工作是否还在变化。
如果系统有明显的夜间空闲，控制器可能利用间隙做后台整理；全天持续写入的服务器则较少享有这种机会。不能用桌面电脑偶尔复制文件的体验估算日志服务器的全天能力。耐用性关注长期累计消耗，稳态性能关注持续服务能力，两者相关但不是同一指标，必须分别设定门槛。
6 常见坑：用峰值吞吐估长期负载
“顺序读取最高 7 GB/s”描述的可能是大请求、较高并发、特定容量和温度下的读取能力。把它用于估算 4 KiB 随机覆盖写，已经同时换了方向、请求大小和访问方式。即便资料明确写的是顺序写峰值，也还需要知道测试范围、运行时长和缓存状态。峰值可以用于理解上限附近的条件，无法单独构成长期负载承诺。
许多 SSD 使用部分闪存以较少位数的模式接收突发写入，常被称作伪 SLC 缓存，随后再整理到更高密度的存储区域。缓存大小可能随可用空间和设备策略变化。这种机制能改善短时写入，却不创造无限介质带宽。持续流量超过后端消化能力时，缓存积压最终会耗尽余量，写入速度便向长期可持续水平回落。
另一个坑是把完成时间的平均值当作所有请求的体验。假设绝大多数写入约 1 ms 完成，少部分需要 50 ms，平均值仍可能看起来不错，但等待这些慢请求的任务会明显停顿。P99 表示在指定统计窗口内，约 99% 的样本延迟不高于该值；它不是最大值，也不能告诉你最慢 1% 内部如何分布。对尾延迟敏感的服务还应看 P99.9 和超时次数。
温度与供电也会制造相似现象。紧凑 M.2 板卡装在散热不足的位置，长时间写入后可能触发限速；服务器托架的风道、相邻 PCIe 卡的热源和机箱布局都会影响结果。若吞吐下降同时温度接近设备限制，先检查散热证据。垃圾回收、缓存耗尽和热限制可能叠加，不能看到曲线下降就立即认定某个单独原因。
还要区分 CPU、内存、网卡和存储各自的瓶颈。25 Gb/s 网络链路的原始速率约为 3.125 GB/s，有效载荷能力还会扣除协议开销；远端写入达不到本地顺序峰值，不一定是 SSD 太慢。加密、校验和、内存复制或文件系统锁也可能先耗尽 CPU。观察整条路径，才能决定应该调整应用、增加设备，还是修复上游限制。
最后，设备出现介质错误、异常掉盘或控制器重置时，不应继续把它当作普通性能调优问题。检查健康日志、操作系统错误和链路事件，并按已有恢复流程保护数据。健康百分比和累计写入量只能提供部分线索，无法排除所有突发故障；多副本、备份与恢复演练仍然是系统层面的责任。
7 案例：写放大拖垮尾延迟
某台服务器把追加日志和频繁更新的索引放在同一块 1.92 TB SSD 上。数据由网卡进入内存，CPU 解析后提交写入。上线初期每天只有约 300 GB 的主机写入，盘内占用约 40%，写入 P99 约为 2 ms。随着保留期延长，占用升到 92%，后台索引整理又在高峰时运行，主机写入增长到每天约 1.2 TB。
故障表象是每天某个时段写入 P99 超过 40 ms，但日平均带宽只有 14 MB/s 左右。这个平均值由全天写量摊平得到，会掩盖高峰时段；它也没有体现设备内部复制的流量。与此同时，少量读取也开始变慢，因为前台读与后台搬运会竞争设备资源。应用看到的是请求排队，SSD 内部看到的是可写空间不断吃紧。
排查先对齐时间轴：应用写入速率、设备队列、P99、温度、健康日志，以及主机和介质写入计数都取相同窗口。确认计数器口径和单位后，发现高峰 30 分钟内主机写入增加 60 GB，介质写入增加 210 GB，窗口 WAF 约为 3.5。温度没有接近限速区，也没有链路错误，CPU 仍有余量，证据因此更支持内部整理压力。
继续检查发现，索引的小随机更新让许多块出现零散无效页，而长期保留的冷数据仍占据大量有效页。回收每个候选块时，需要搬走的有效内容增加。设备同时承受主机新写入和内部复制，可用页补充跟不上消耗，部分回收就进入前台等待路径。写入完成变慢后，上游待处理队列积压，又进一步放大了应用感受到的尾延迟。
团队分阶段调整：先错开索引整理的时间，并限制其并发；随后缩短本地数据保留范围，把适合归档的冷数据迁走，确认释放通知能够传到设备；最后把持续追加与高频随机更新拆到不同设备。每次只引入可解释的改动，保留相同高峰负载下的观测窗口。拆盘增加了硬件成本，但也让容量、寿命和故障影响范围更容易分别管理。
调整后的某个可比窗口内，主机仍写入 60 GB，介质写入变为 108 GB，WAF 约为 1.8，P99 降到 8 ms。这里的数字是教学案例，不能承诺同样操作必有同样收益。有效结论是：占用、负载组合、内部写入和尾延迟的变化能够相互印证。若只有占用下降和延迟下降，却没有介质计数，就应保留其他解释，不把写放大说成已被直接测得。
8 把 SSD 特性写进存储选型
选型表应从负载开始填。至少写清容量增长、读写比例、请求大小、顺序与随机分布、每日主机写量、并发程度、延迟目标，以及是否要求持续持久化确认。还要区分平时和高峰：日平均 20 MB/s 的系统，可能在短时窗口集中写入 400 MB/s。对窗口没有说明的“吞吐要求”，不足以判断缓存和介质能否持续接住数据。
把容量分成实际数据、日志和临时工作空间，再加计划保留的空闲余量。例如，预计峰值占用 1.2 TB，希望长期至少保留约 25% 的主机可见空间，则容量门槛约为 1.2 ÷ 0.75，即 1.6 TB，实际还要计入增长与文件系统开销。这个余量是项目假设，应通过测试校准，不是宣称所有 SSD 都必须留同样比例。
再核算写入耐用性。若每天主机写入约 1 TB，计划使用 5 年，基线累计写量约为 1825 TB；增长、维护重写和异常重试还需额外预算。比较资料时核对 TBW、DWPD、容量和期限的口径，避免把不同容量型号的数据混用。对于主机写量本身波动很大的系统，可设定滚动窗口观察消耗趋势，及时调整保留期或安排替换。
机器形态会限制方案。小型主机可能只有 1 个 M.2 插槽，散热与容量扩展都较紧；服务器则可能提供支持热插拔的托架、多个独立设备位置以及更完整的健康监控。接口外形能插上不代表协议一定兼容，还要查主板、背板和转接组件。多个插槽也可能共享上游 PCIe 带宽，不能直接把每块盘的峰值相加当作整机能力。
对于已确认写入必须抵抗突然掉电的场景，应核对设备的断电保护范围、易失性写缓存配置，以及主机持久化命令是否正确使用。板上有电容不等于满足所有持久化要求，没有独立 DRAM也不等于不存在易失状态。采购参数、软件调用和断电恢复测试应围绕同一个持久化目标对齐，不能靠单个器件外观推断数据是否安全。
验收最好写成可执行的条件：在指定容量占用、温度范围和预处理之后，以目标请求分布运行，检查持续吞吐、P99 与 P99.9、错误日志和写入消耗。再加入备份、恢复时间与替换流程。若 1 块设备的长期写入能力不足，可以降低写量或分担负载；若要求单设备故障后继续服务，就需要额外冗余，并验证冗余恢复期间的性能与写入预算。
9 从 SSD 内部走向 NVMe 与存储协议（H29）
现在可以把写入分成几段理解：应用提出需求，操作系统组织请求，协议把命令送给设备，控制器映射地址，闪存完成编程或触发整理。前面几段决定设备收到什么以及何时收到，后面几段决定它如何消耗内部资源。某段传输更快，不会消除页、块和擦除约束；内部介质更强，也不能弥补软件把请求串行化造成的闲置。
下一课讨论 NVMe 时，要带着 3 个问题：主机怎样把命令交给设备，设备怎样报告完成，多个请求怎样并行推进。提交队列、完成队列和门铃等概念将用于回答这些问题。本课先不展开寄存器布局、队列仲裁与协议细节，只把队列看作尚未完成的工作集合，理解并发既可能提高利用率，也可能增加等待。
一个简单例子是：若设备平均每个请求需要 100 μs，在完全串行且无其他开销的理想情况下，每秒约完成 10000 次请求。更高并发可以让不同内部资源重叠工作，但吞吐不会无限增长；当共享资源饱和后，继续堆积请求通常只会拉长延迟。因此“支持很多队列”和“在目标 P99 内提供足够服务能力”需要分别验证。
还要把协议完成与业务完成对齐。普通写入返回、要求持久化的同步操作完成、文件系统元数据达到可恢复状态，是不同层次的事件。文件系统与数据库会使用相应机制实现它们需要的语义。H29 会进一步解释主机与设备之间的命令边界，但协议名称本身不替代断电保护，也不替代应用自己的事务与恢复设计。
读到新设备参数时，先问它属于哪个层次：GB/s 描述某种负载下的字节速率，IOPS 描述请求完成数量，微秒或毫秒描述时间，TBW 描述规定条件下的累计写入指标。它们不能互相替代。把请求大小、并发、读写方向和运行状态补全后，这些数字才可以连成一个有意义的系统模型。
到这里，你应能用页与块解释覆盖写，用 FTL 解释地址稳定，用垃圾回收解释额外搬运，并把这些机制连接到写放大、耐用性和尾延迟。再遇到“刚开始很快，持续写后变慢”的问题，就有了可以验证的候选原因：缓存、空闲余量、内部回收、热限制和上游瓶颈。接下来的协议学习，会帮助我们把主机侧的证据也补齐。
放进方案里
在方案中为 SSD 写一段可验收的约束，不要只写“配置高速固态硬盘”。例如，某台服务器需要保存最多 1.2 TB 的在线数据，每天预计向设备写入 0.8 TB，以 4 KiB 随机更新为主，同时有较大的顺序追加。明确这 0.8 TB 来自主机接口统计，并说明是否包含日志、索引维护和备份产生的写入，避免把业务新增量误当成实际设备负担。
容量按峰值数据、临时空间和增长估算，计划保持至少约 25% 的主机可见空闲空间，并验证文件系统的释放通知能贯通整个存储路径。若计划运行 5 年，基线写入预算约为 1460 TB，再根据增长和维护任务补充余量。用这个主机写入预算核对候选设备的耐用性条件，同时确认服务器插槽、背板、协议支持、散热和供电满足要求。
性能条款写清负载与窗口。例如，在约定占用率、温度和预处理条件下，持续运行 60 分钟的目标读写混合负载，要求吞吐覆盖业务高峰，写入 P99 不高于 10 ms，并记录 P99.9 与超时次数。60 分钟只是本项目的验收窗口；若缓存和后台整理仍未进入稳定范围，就延长测试。不能把短时峰值替换成这项验收，也不能把其他请求大小的成绩直接套用。
运行期按相同时间轴采集主机写量、延迟、温度和错误事件；设备支持且口径明确时，再加入介质写量与窗口 WAF。若尾延迟升高，先核对队列、温度、空闲空间和维护任务，再决定限流、迁移冷数据或拆分负载。方案还应约定断电持久化目标、备份恢复办法和设备替换门槛，使性能下降与设备失效都有对应动作，并把实施后的同负载复测作为变更完成条件。
10 小结：下一步 NVMe 与存储协议（H29）
SSD 的核心约束是页级编程与块级擦除。FTL 允许逻辑地址保持稳定，垃圾回收让物理空间重新可写，也带来额外搬运。写放大把这些内部成本与长期写量连起来，预留空间、负载分布和设备状态则会改变它的实际大小。
自测时试着解释：为什么无效页不能立即覆盖？为什么只知道主机写入量不能测出介质 WAF？为什么空盘的短时顺序写结果不能证明高占用随机写的 P99？能说清这 3 点，就已经抓住本课的主要因果关系。
下一课进入 NVMe 与存储协议（H29），沿主机提交请求、设备执行和返回完成的路径，继续理解接口并行、命令语义与系统延迟之间的关系。