映射表规模是容量的线性函数
FTL 的核心是逻辑页到物理页的映射表。以 4KB 为间接单元、每条表项 4 字节计算，映射表大小约为盘容量的千分之一。J750 的 15.36TB 档位对应的完整 L2P 表接近 15GB，而盘上 DRAM 通常也按容量的千分之一配置，看似刚好够用，但这块 DRAM 还要承担写缓存、日志、坏块表、读电压校准表等结构，真正能留给映射的空间总是不足。容量继续向上走时这条约束更紧，全产品线规划的单盘最大容量已到 122.88TB，全表常驻在任何合理的 DRAM 配置下都不成立。
分级缓存的边界怎么划
可行的做法是把映射表按固定大小切成映射页，完整表常驻 NAND，DRAM 只缓存活跃的映射页，控制器内的 SRAM 再缓存最热的一小部分表项与目录结构。三级之间的差别不只是容量，更是访问代价：SRAM 命中在数十纳秒量级，DRAM 命中在数百纳秒量级，而从 NAND 取一页映射意味着一次完整的介质读，代价与一次用户数据读相当。
未命中直接落在尾延迟上
映射未命中的后果是把一次读变成两次介质访问。J750 与 J770 规划的 QD1 读延迟目标是 65µs，未命中路径几乎等于翻倍，而这类事件在平均值里几乎看不出来，只会在 p99.9 与 p99.99 上抬头。更麻烦的是它与工作集大小强相关：随机读的地址范围一旦超出 DRAM 所能缓存的映射覆盖范围，命中率会在很窄的区间内快速塌陷，表现为负载稍微放大就出现延迟台阶。因此评估映射缓存不能只看一个平均命中率，要扫描工作集大小画出命中率与尾延迟的曲线，确认塌陷点落在哪个容量位置。
间接单元粒度的取舍
把间接单元从 4KB 放大到 8KB 或 16KB，可以成比例地压缩表规模，代价是任何小于间接单元的写入都要先读出整个单元、合并后重写，直接抬高写放大与写延迟。这条取舍在产品线内部呈现为清晰的分工：Q7 与 Q9 系列面向对象存储、备份归档与 AI 检查点这类以大块顺序写为主的场景，容量优先，粗粒度带来的代价可以接受；X7 与 X9 系列面向元数据、日志、缓存层与 KV Cache，负载本身以小块随机为主，粒度必须保持细，命中率的优先级高于表占用。
除了调粒度还能做什么
工程上还有几条常用手段：对顺序流采用范围映射，用一条表项覆盖连续的大段地址，顺序负载下表占用可以下降一个量级；对映射页做预取，利用访问的空间局部性提前载入相邻映射页；把映射更新的落盘做成日志加检查点，避免每次更新都重写整页。这些机制的收益高度依赖负载形态，需要用真实访问轨迹回放来标定，而不是靠合成随机负载给出结论。上述数值均为设计目标值。