1个多月前，我发了个帖子是说关于840 Evo更新固件后有用户反馈的Linux下Trim导致数据出错的问题，其实850Pro “砖头门” 这版的固件也有这个问题。 既然这2个问题的共同点是Linux，Trim，数据出错，三星SSD。那么我们今天就围绕SSD的Trim来展开。
Trim是什么？为什么需要Trim？
当初PCEVA做美光SSD专题时，有对Trim指令进行了介绍，详细可以见这里：http://www.pceva.com.cn/topic/crucialssd/index-6_6.html
简单来说，Trim就是当用户删除文件的时候，文件系统通知SSD控制器，这个逻辑地址对应的物理地址文件已经无效，你做垃圾回收时候不需要再浪费时间搬运了。
Queue Trim的基本概念
在早期的SATA协议标准里，标准的Trim属于一条non-queued指令，也就是说需要先暂停所有的读写操作并释放缓存里的数据到硬盘之后才能执行Trim操作。我们知道SSD的并发性能很强，通过AHCI支持NCQ后，多QD下同一时间的IOPS非常可观。在高负载并发读写进行的时候经常的忽然进行标准的Trim指令就会严重影响性能了。表现就像下面这样：
-数据传输- -数据传输- -释放缓存到硬盘- -等待- -TRIM- -数据传输- -数据传输-
如图标准Trim指令会打断NCQ。
为了解决这个问题，在SATA协议3.2版里加入了Queue Trim的支持，就是能够在NCQ里执行Trim了，做Trim的时候不需要暂停SSD的I/O操作了。表现就像下面这样：
-数据传输- -数据传输- -TRIM- -数据传输- -数据传输- -数据传输-
目前只有新版的Linux内核下支持Queue Trim，Windows和MAC OSX这类系统并不支持。
目前已确认三星的8系列SSD新版固件开启了Queue Trim支持，但是支持的不好会导致数据损坏
如图，拿我手上的SSD来说，Intel 730 并没有Queue Trim的支持，而更新了新版固件的840 Evo却支持了Queue Trim。（看Word 77的6 - RECEIVE/SEND FPDMA QUEUED supported，如果为1就是支持Queue Trim）。很明显三星新版8系列SSD固件支持了SATA 3.2标准并且默认激活了Queue Trim功能，但是支持的却并不好，会导致用户数据出错。
三星对Queue Trim的答复与解决对策
关于Queue Trim的问题有位用户反映给三星官方客服后，第一次他提到了NCQ Trim造成数据出错，但是没提到Linux，结果客服给了如下回答
客服直接就说了三星SSD对Linux下的Queue Trim支持有问题，建议禁用。（也就是说三星内部已经知道Linux下的问题）
第二次这位用户详细解释了为什么会造成盘故障的问题，强调说盘的固件有问题。
结果依然得到了模板一样的回答。
第三次他一点不提Trim的字眼，这一次客服算是看了来信并回答如下：
客服强调他们是售后支持，并不是固件开发工程师，固件开发工程师在韩国。目前的建议就是让用户更新最新的 Linux内核，而最新的内核里面是禁用全8系列三星SSD Queue Trim功能的“补丁”。
其实在2个月前我还有个帖子是关于840Pro在Linux下严重掉速的，这样看来三星客服的回答还真没错，三星对Linux这种开源系统不予支持。三星要做的其实就是发布新固件关闭这个Queue Trim功能的支持，要么就是真的好好去重新做个能够完美支持Queue Trim的固件。
我在想如果三星不修复这个问题的话，万一之后的Windows 系统哪天来个补丁支持Queue Trim，或者MAC OSX支持Queue Trim的话是否全世界用三星SSD的用户就热闹了？丢数据的丢数据，变砖的变砖了？
三星SSD的Trim还有什么问题？下面是我的分析，仅与技术人员讨论
上面是已知的对Queue Trim支持问题，那么下面我再来说一下这几天新闻里说到的 ”部分三星SSD出现TRIM执行bug：数据被破坏、后果很严重。“
这个文章最近最近各处被转发，而且已经出现了新的中文标题：三星SSD 8* 等系列新firmware 存在误报支持NCQ TRIM 导致数据丢失的问题。其实我想说，这次貌似和Queue Trim又没关系了。原文出处地址：https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/
原文作者已经表示他们并没有开启Queue Trim。
作者上面的图里显示，General Purpose Log 0x13 does not exist ，这个就表示Queue Trim 并没有启用。
既然不是Queue Trim的问题，那是什么导致了三星SSD Trim下去后数据出错呢？
Firmware bug造成Delay Trim （延迟Trim） 操作导致的数据出错。
这个bug是一个隐藏的很深的bug，只有在大压力测试下才会出现，原文作者是做数据库index操作，非常折磨ssd，windows做做文件系统这些小事，一般测试不出来的。数据出错的原因是做trim操作时，将有效数据trim掉了。
什么是Delay Trim ？ 为什么我可以确认三星做了Delay Trim？
这个我们在2年前讨论840 Pro的Trim策略时候有过帖子： 三星840PRO垃圾回收策略探讨
总结部分我们提到说：三星在GC策略上，的确采取了非常保守的算法。因此导致前面如果在刚发送完Trim指令就执行测试的时候，由于SSD实际根本没有执行后续必要的GC操作，从而无法得到很好的测试成绩。
Trim的发送包含2个要点，1个是Trim指令本身，另一个是需要Trim的地址范围（LBA地址范围），一条Trim指令发送需要至少包含1个扇区号，也就是512字节。支持的Trim指令的地址范围取决于所使用的SSD，最大不能超过65535扇区，也就是不到32MB。
前面说过了，在不支持Queue Trim的情况下，由于Trim操作需要暂停并发读写指令，因此会影响性能。那么如果每次Trim的地址范围偏小，多次Trim的话更会影响性能。假设我们现在把每次Trim的地址范围缓存起来一段时间，如果在这段时间有更多需要Trim的地址范围加进来，那么我们就可以一次发送更大范围的Trim了，这不就降低了频繁打断并发读写操作的可能吗？ 这个操作就叫Delay Trim。
Delay Trim是把双刃剑，做的不好非但会掉性能，还会有数据安全隐患。
假设SSD缓存了几次Trim地址范围但是还没有做Trim，这时候Trim的地址范围如果是放在缓存里的，此时突发掉电的话会如何？再次上电后这些Trim地址就没有了，也就是说Trim没效果了，当然这不影响数据安全，但是可想而知这会影响性能表现和垃圾回收效率吧。
那么这里说的数据安全隐患是什么呢？假设缓存的Trim地址范围在缓存里出错了，或者在缓存的这段时间里漏掉了某些SSD读写操作逻辑地址（在压力大的情况下更容易发生），造成将有效数据给Trim掉了。（这是完全有可能的，比如这个地址被文件系统标记Trim（删除操作）并发送给SSD主控，但是在之后的操作中被后来的新数据覆盖了，主控因为延迟Trim的发送将这个地址范围给Trim掉了，导致新的有效数据无效化了。
由于标准Trim的地址是512B为最小单位的，因此表现出来的就是如作者这里写的，小文件（小于512B）被清零了（Trim掉），运行文件检测的时候发现不了错误，因为文件在内存里的副本是好的，重复读取这些小文件都是访问的系统内存，而大文件内随机的地址被清零（某些地址范围被Trim掉）。用户的文件就这么出错了。
这不前几天还有网友问，为什么他的SSD做Trim或者快速格式化后，在那里卡几十秒呢？因为这些SSD不支持Delay Trim呀，所以如果Trim掉的无效数据多，之后的垃圾回收需要消耗较长时间去擦除这些数据。也就是暂停所有读写，Trim了并且直接垃圾回收，性能恢复了也以绝后患。
最终建议，企业级客户目前最好远离三星。消费电子嘛，本来就不能用于严肃的场合，换身衣服就装企业级的不算。话说阿里巴巴不是有高官因为采购三星ssd被fire掉了么，要我说数据库或者非Windows这种随大流系统还是别碰三星的SSD了，乖乖Intel之类的吧。
题外话：好像还有人蛮期待我的“长篇黑文”的。还有人对我长期“黑”三星很是不满意。但我想问问：你要是负责企业存储的技术人员，现在你会选择三星的SSD吗？没中招的还好说，换个品牌采购即可；对于已经中招的企业，怎么解决问题才是关键。这些都是切实的技术层面与每个企业的自身利益问题，跟立场毫无关系。你们这些枪手、粉丝，考虑过别人的利益吗，考虑过别人被坑后的感受没？如果没有，在给三星的问题产品洗地之前先抽自己几个耳光可能就知道了。
说点心里话，我觉得技术讨论就是技术讨论，黑不黑捧不捧的跟我有啥关系？从原理分析到实测表现再到各种功能的确认，最后能跟同好讨论点真相出来，这才是我关心的问题。现在就是互联网就有这么一堆自己带着有色眼镜的人，他们用立场角度去判断别人的价值观的是非，但自己却连事情到底怎么回事都搞不清楚，更别提分享什么有价值知识了，请问他们有享受言论自由的资格吗？还好我心里强大，常人被这样污蔑可能早就不敢说话了吧，他们的目的也就达到了不是？对他们我就一句忠告：回家把书念好了再喷，学渣是没有资格评论我的。
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有帐号？注册
x
评分
-
查看全部评分
|
收藏
转播
