Nimble 的CASL相关性能问题

1. 前端 IO 大小不限制 主机下发可以是 4k/8k/16k 各种随机大小、LBA 不连续的随机写，直接进入 NVDIMM 持久缓存，主机收到 ACK 是在写入 NVDIMM 完成时。
2. NVDIMM 内：收集、变长压缩、合并，凑整 stripe

• 压缩是变长块压缩，不是固定块；压缩后实际数据体积会变小。
• 系统会持续积攒，尽量攒出完整 RAID 条带再落盘；混闪 CS 系列整条 stripe 很大（官方资料混闪约 18MB、全闪 AF 约 10MB），并不是 256KB，256K 只是很多传统阵列的条带大小，不要混淆。
• 如果业务写入速率很低，长时间凑不满完整 stripe，CASL 有超时机制，到时间即使没攒满，也会把当前缓存数据顺序刷下去，不会无限等。

3. 后端落盘：100% 顺序追加写 不管前端是多碎的随机写，最终写入后端 HDD/SSD 介质都是顺序追加，不再存在随机寻道。混闪场景下，这就是为什么 HDD 也能跑出很高随机写性能的根本原因。

容易踩的性能误区（重点）

1. “随机写全部变顺序写” 只针对后端持久介质，读 IO 不受这个机制影响；读是走 SSD 缓存命中，冷读才去后端介质。
2. 不是无上限无限合并：NVDIMM 容量有限，写压力大的时候，来不及攒满整条 stripe 就会触发刷盘，此时落盘块会小于完整 stripe，但依旧是顺序追加。
3. 重删是独立流程：CASL 的在线压缩和变长重删是分开的，重删会消耗控制器 CPU，在极高 IO 压力场景会带来性能影响。
4. 混闪场景短板：大量持续大顺序写业务会快速打满 NVDIMM，来不及聚合，刷盘压力变大，此时 CASL 的优势会被削弱；CASL 最大优势场景是虚拟化、数据库这类小块随机写业务。

一句话精简总结

主机随机小块写进 NVDIMM 缓存，系统压缩、聚合，尽量凑整条大 RAID stripe（混闪～18MB、全闪～10MB）顺序追加落盘；不是固定变成 256KB 块，低负载会超时刷写部分填充的条带，但后端写始终是顺序写。