另外一点，我认为okko没有提到，SandForce 2系列主控虽然对处理NAND的效率方面做了很大改进，如你所说去掉压缩这层后基本等同于M4，不过他的算法上也有致命的一点。
众所周知SandForce没有大容量外置缓存,所以他的映射表(肯定是page mapping)大部分是做在闪存里的，所以当用户写入的数据不能压缩时，其实写入放大真的不低。（绝对不是1，至少在3以上）。
他的数据是通过闪存做了2级映射表。首8GB（我猜测的容量，实际可变）的不可压缩容量应该可以被第一层映射表笼罩（主控内SRAM可以优化），所以测试软件跑出来分数都不错。（一般测试软件测不到8G外的容量，况且数据大都可被压缩）。而之后的数据，由于主控缓存需要2次加载映射表（缓存装不下），造成了延迟增大（闪存延迟），即使主控的压缩是on the fly的，但是此时已经无法避免闪存原本的延迟，造成了寻址时间被闪存拖累并增大，随机数据的下降，继续下去，会造成主控不堪重负，所以SandForce主控会强制限速到我们常说的“GC态”，在“GC态”下的分数，就没有上面okko那么好看了。如果这种测试环境还在继续，那么“GC态”后更恶劣的“限速态”就会产生，这就是因为写入放大被拉到了2位数以上造成的。
所以我认为，SandForce在处理不可压缩数据的时候，前期写入放大可以做到1~3附近（1级映射表），而后期由于需要2级映射，写放大 + 垃圾回收后（1级，2级映射表都需要做垃圾回收），写放大最大会到10以上。当然这些可以靠预留空间增大来改善 ，所以企业级SandForce的OP容量都很大也是这个道理。
另一个不可避免的问题是如何确保Trim的指令能正确无误的发送到对应的地址。（数据已经被主控压缩处理，也就是说Trim指令也需要处理后才能定位到正确地址。）这可能就是SandForce主控做Trim的时候非常慢的道理，而且目前看来无解。 |
