SDNAND 写入偶发几十毫秒延迟，是 GC 导致的吗？

SD NAND-贴片式TF卡-贴片式SD卡-免费测试2026-10-224

连续写入中偶发的几十毫秒延迟，很大概率就是垃圾回收（GC）造成的。你关于小数据量写入和空闲回收的策略思考，也抓住了 SDNAND 这类受管 NAND 的核心特性。

几十毫秒的延迟，是 GC 导致的吗？

是的，这很典型。

SDNAND 内部集成了闪存控制器（FTL），GC 完全由芯片固件自主管理，主机既无法干预，也无法直接感知。当你在连续写入时，控制器如果手头有空闲块，写入会很快；但如果空闲块不足，就必须先搬移有效数据、擦除一个旧块，才能腾出空间写入新数据，这一次写入的耗时就会被显著拉长。这就是写入延迟抖动的直接来源。

你的几十毫秒延迟完全在合理范围内。有资料指出，GC 触发时写入延迟可能增加 50%–200%，在更差的情况下（如 SPI 接口+随机写+GC 触发），延迟甚至可能达到秒级。对于 SDIO 接口的正常场景，偶发几十毫秒的停顿是 GC 在后台工作的典型表现。

写满后循环写入，GC 时间大概有多少？

这个问题没有一个固定的“标准答案”，它高度依赖于空闲块的数量、数据的碎片化程度以及主控算法的效率。

不过可以给你一个量级参考：在存储空间紧张、需要频繁回收的情况下，单次 GC 操作（搬移有效页+擦除块）导致的写入停顿，通常就在几十毫秒到几百毫秒这个范围。如果空间极度碎片化（例如大量小文件反复增删），GC 触发会变得频繁，掉速和延迟抖动会更明显。

你提到的“写满了再循环写入”的场景，正是 GC 压力最大的时候。此时写入性能的稳定性，极度依赖于控制器能否高效地找到“无效页比例高”的块进行回收。

TRIM（CMD38）的作用与你策略的印证

你对 TRIM 的理解是准确的。TRIM（SD 协议中通过 CMD38 实现）的核心作用，就是提前告诉主控哪些数据块已经无效、可以被回收。

如果主机不发送 TRIM，主控在它看来所有块都存着数据，无法区分有效数据和已删除的“垃圾”。这会导致两个后果：GC 效率极低（可能被迫搬移大量实际已无用的数据），以及写放大加剧。因此，TRIM 对于维持长期写入性能、延缓“越写越慢”的趋势至关重要。

你总结的策略非常符合工程实践：

“小数据写就主机 trim 比较好，因为回收频发”：完全正确。小数据量、高频率的写入（如日志、传感器数据）会快速制造大量无效碎片。主动 TRIM 能帮助主控精准识别垃圾，让 GC 工作得更有效率，避免无效搬移。
“大数据写，不 trim 也可以”：也有道理。大数据量的顺序写入，本身产生的碎片相对较少，GC 压力没那么大。此时 TRIM 的边际收益会降低，而且频繁发送 TRIM 命令本身也有协议开销。
“我们会在空闲时做回收，主机感觉不到”：这正是 SDNAND 控制器设计的核心目标之一。许多控制器会利用总线空闲时间（BKOPS，后台操作）来执行 GC，尽量将对主机写入性能的影响降到最低。你观察到的几十毫秒延迟，很可能就是空闲回收来不及完全“消化”垃圾，GC 被迫在写入路径上“抢跑”的瞬间。