黑五期间OCZ在美亚好价不断，让不少朋友得以圆梦旗舰型号或是大容量入门级。当然随后也发生了1546批次的部分ARC100产品出厂健康度显示异常的问题，以及最近的Vector 180“卡顿”和“Trim BUG”事件。这次Vector 180的卡顿问题主要集中在删除大容量数据之后出现，因为SSD容量不比机械盘，多数人都是作为系统盘使用，很少会将大体积文件存储在SSD上，删除大容量数据后的Trim卡顿问题隐蔽性很强，如果不是有人提出来V180卡顿，我都差点忘记自己也有一块Vector 180 240G。
重现卡顿：
当Vector 180一次性删除大容量文件之后，通过Windows 10任务管理器可看到磁盘活动时间长期保持100%状态，平均响应时间超过500毫秒，同时硬盘灯常亮。有人指出这个时候Vector 180的读写速度都很低，这是因为此刻Vector 180基本已经失去响应，几乎不接受读写指令，所以没有速度。Ramaxel最早提出他的Vector 180使用WMP播放抓取的CD音轨文件时有卡顿现象，在当时被认为是不可思议的，但我自己测试后发现，这种集中删除大容量文件导致的SSD停止响应的确可以引发这种现象。下图是一次性删除35GB文件后任务管理器磁盘100%活动时间，大约持续30秒。因为我的Vector 180只有240G，一次性删除35GB文件几乎已经是我能够测试的极限了…
其实这个现象不止发生在Vector 180身上，ARC100也有删除大文件后磁盘活动时间100%的问题，不过ARC100用户那么多，从来没人提起过这种情况会导致卡顿，这还是因为这个问题的产生情景局限性：SSD容量本身不大，而只有一次性删除大容量文件才会诱发这个问题。
除了以上的“卡顿”情况外，还有一种被认为是“卡顿”的情形，那就是持续写入曲线会有一些低谷，这应该是Vector 180特有的PFM+所引起的。除了HDTune文件测试之外，在文件复制过程中也能看到周期性的短暂低谷出现，产生这样短暂写入速度低谷的原因是断电保护功能需要经常将DRAM外置缓存当中的数据回写到NAND闪存当中，会与用户写入产生争抢资源的情况，当然这不会完全阻断硬盘写入能力，也就不会引发可感知的使用中卡顿的感觉。下面讨论的“卡顿”都与这个现象无关。
为何卡顿？卡顿时盘在做什么？
提起卡顿，很多人会联想起“掉盘”二字，不过Vector 180卡顿时间过后会自然恢复，并不会有掉盘现象。当Vector 180作为系统盘使用时，删除大容量文件引发卡顿的现象最容易观察到。如果将Vector 180作为副盘使用，如果删除后没有对SSD进行其他访问，磁盘活动时间不会飙升，内部垃圾回收会在静默中度过。
由于卡顿基本都是在删除大量文件后出现，所以很容易想到卡顿与Trim之间的关联。SSD主控在收到Trim指令后可以了解到哪些区块数据无效可以进行垃圾回收。卡顿的过程Vector 180显然是埋头苦干去做垃圾回收了，以至于主人叫他都不应答了。在禁用Trim后卡顿消失，也说明卡顿的源头在于Vector 180进行垃圾回收工作造成。
为何禁用Trim后卡顿消失了？
禁用Trim以后，Vector 180无法感知到被删除文件的区块已经无效化，不能立刻做出垃圾回收，只有当下次操作系统再次要求向同个LBA地址写入时，Vector 180主控才能知道这个区块原有数据已经无效了，可以回收了。由于没有了大范围区块需要一次性集中做GC垃圾回收，可感知的持续卡顿现象也就消失了。不过禁用Trim会导致垃圾回收效率下降，对写入放大率也会有一定负面影响。
既然是Trim造成的，为何其他盘不会这样，OCZ的Trim效率比别人低？
SSD接受Trim指令，然后根据情况进行垃圾回收，在所有SSD中都是这样进行的，只是GC垃圾回收的时机与策略各不相同。OCZ的垃圾回收策略是比较积极的，在收到Trim指令后会立即进行完整的GC垃圾回收，完整的GC是一个较为耗时的工作，因为NAND闪存的擦除延迟比编程延迟更大。在Trim指令执行完之前，SSD将无法接受其他指令，这是因为Trim是一条non-queued指令，不能与其他指令一起并发执行。现在很多SSD选择了delay trim（延迟Trim）的策略，删除大文件不会立即引来卡顿，即便是全盘格式化发送全盘Trim指令这种情况，他可以很快甚至是瞬间完成格式化过程。全盘格式化意味着下达全盘LBA范围的Trim指令，瞬间完成显然是不可能的，这些SSD主控只是接受Trim指令并将相关信息记下来，待以后再做。所以说并非OCZ的Trim效率低，而是他选择了在收到Trim指令后很快执行完整GC垃圾回收，毫不拖沓，当然用户也许会因此很快感受到删除大容量数据后带来的垃圾回收卡顿。
一次性删除大文件会导致SSD卡顿的问题其实并不新鲜，早在今年6月论坛就有人提起过：http://bbs.pceva.com.cn/thread-120287-1-1.html，这个帖子的楼主所用的是浦科特M5S，可见这个问题并非OCZ独有的，也不能简单归类为BUG。一条Trim指令只能处理最大相当于32MB的地址范围（65535扇区），可以想象删除大容量文件会引发一波Trim指令潮，同时由于Trim是个效率低下的non-queued指令，只能一条一条来，不但自己不能并发执行，并且在执行Trim的时候还会打断其他读写指令，对于SSD来说是个很霸道的独占者。在Windows支持Queue Trim之前，要改善这个问题只能借助于delay trim，也就是说SSD主控收到Trim指令后首先只做记录，而不忙实际马上执行相应的垃圾回收，或者是内部给垃圾回收一个较低的优先级，后台慢慢执行，尽量不产生持续卡顿。
为何OCZ这么急于做完整GC？这是一个BUG吗？
别的SSD或许都可以把接受Trim指令后的垃圾回收工作押后进行，避免立刻带来可感知的卡顿，但OCZ似乎有更多苦衷无法这样做。
使用Barefoot 3主控的OCZ SSD有一个共同的特点：动态SLC Cache。所谓动态SLC Cache其实就是SSD会根据盘内空间使用情况随机进行调整，始终让全部剩余空间都可以作为SLC Cache实现高速写入。在这些SSD当中，没有固定的SLC Cache大小，盘内剩余空间全部都是SLC Cache能使用的范围，最大化利用了全部盘内空间。下面一组测试是不断减少Vector 180盘内剩余空间，可看到SLC Cache的大小也随着动态改变，SLC Cache大小始终是包含OP空间后全部剩余空间的一半左右（MLC当作SLC操作，所以SLC模式可写的容量只有MLC容量的一半）：
这项动态SLC Cache技术最早是从Vertex 4时代开始实现的，在浴室当时的Vertex 4测试帖当中已经能够看到Vertex 4的1.5版固件已经实现了动态SLC Cache的雏形：即便写到接近满盘，通过快速调整后依然能够提供剩余容量的一半作为SLC Cache使用。
正因为动态SLC Cache需要随时调整盘内空间，所以OCZ不得不即刻做垃圾回收，将无效的数据块擦除，以便让这些剩余空间马上加入到动态SLC Cache可利用的范围内，所以我认为OCZ在收到Trim后立刻进行完整垃圾回收的策略未来应该不会改变。消费级SSD多数着眼于爆发性能，包括SLC Cache本身就是一种提升爆发写入的做法，那么鱼与熊掌不可兼得，在享受动态SLC Cache所带来的充分利用所有空间的好处后，特定情况下的删除导致卡顿的问题也是难以完全避免的。虽说改进空间也是有的，但由于涉及到固件底层调整，由改动带来的一系列验证工作量很大，更可能影响到稳定性表现，这显然是OCZ和用户都不想看到的，所以我个人认为OCZ为此发布新固件进行调整的可能性不大。
现在SSD的主流容量决定了SSD作为数据存储盘使用的情景不多见，这个缺点依然是在可控范围之内。如果自身使用需求确实包括持续高速写入和快速删除不卡顿两个方面，我认为应该选择其他SSD产品。OCZ为Vector 180标注的建议写入量为每日50GB，那么一天写入50GB的话，每天又能删除多少数据呢？总得先有了写入你才能删除吧~如果不是集中的一次性删除大容量数据，就不会遇到垃圾回收带来的卡顿问题。Vector 180虽然定位旗舰级，但同样也是作为家用消费级SSD进行固件调教的。
增设OP后能提高Trim效率吗？能解决Trim大量数据GC耗时长卡盘的问题吗？
我进行的简单测试里，使用SSD Guru为Vector 180增设OP，对同样数据量文件删除后引发的垃圾回收所消耗的时间没有明显变化。
这个问题影响有多大？应该如何应对？
由于删除文件引发的垃圾回收卡顿在ARC100上同样可以出现，ARC100的用户群体显然比Vector 180要大的多，而通过大量ARC100用户长期使用的反馈来看，这一问题对日常使用的影响并不大。当然Vector 180在增加了PFM+断电保护功能之后，需要更加频繁地定期回写DRAM中的数据，理论上可能会令垃圾回收造成的卡顿有所加剧，不同容量的Vector 180表现可能也会有差异，是否会影响使用最终还是要取决于SSD的使用环境。
我在将Vector 180 240G作为系统盘使用的过程中没有遇到由SSD引起的可感知的明显卡顿，对正常使用这点倒是不必担心。如果已经购买Vector 180，平时又的确有集中删除大容量文件的使用需求，可以考虑关闭Trim，只在必要时使用OCZ SSD Guru工具箱进行手动Trim。另外Windows 8.1以上系统针对SSD有定期优化功能，如果没有改动过设置的话，系统默认是一周执行一次Trim。
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有帐号？注册
x
|
收藏
转播
之前浦科特卡GC，现在ocz又卡GC
手上那块SF1222的OCZ 3.5寸用得好好的。。
