本帖最后由 nighttob 于 2014-9-12 00:25 编辑
大家都知道Intel 520的SF-2281主控具备数据压缩的能力(DualWrite技术)，于是我想实验一下，这个数据压缩会不会被RAID 0条带(Strip)所影响。
在开始正文之前，先解释一下为什么标题里有“不完备”。
1. 实验精度不足。
我们都知道如果一块SSD如果没有数据压缩能力的话，其NAND写入量必然是大于主机写入量的，而如果具备数据压缩能力的话，NAND写入量就可以小于主机写入量。NAND写入量和主机写入量之间的比值，也就是我们常说的写入放大倍率(WA)。
对Intel 520这款SSD来说，计算WA很容易，因为其SMART报告了NAND写入量(F9)和主机写入量(F1)。但是，SMART报告的数据精确度并不高，F9的精度是1GB，F1是32MB（详细解读见http://bbs.pceva.com.cn/thread-96031-1-1.html）。这也就导致计算出的结果，在数值较小的时候，误差很大。除非把写入量提升到TB级别，这样才能在宏观上减小精确度不足带来的误差，但这么做的代价太大，一个完整的实验做下来需要写入几十TB数据，耗时几个月，我没能力做到。
2. 测试方式可能不合理。
我采用的方式是不断写入一组持续数据，这组数据可以被SF-2281的DualWrite技术实时压缩，但并不是全0全1这样的理想数据。也就是说，把这组数据写进520以后，NAND写入量和主机写入量之间会有一个比较显著的差异，便于观察结果。
问题在于我的这组数据是否与我预想中的一致，虽然宏观上是可压缩的，但分解到条带水平上是否符合预期，这不能肯定。另外简单粗暴的组一个RAID 0，分区，然后直接写入方式是否适用于这个实验，也是个未知数。
3. 没有理论基础。
这点极为关键，因为我并不清楚DualWrite技术的细节。如果这项技术做的足够周全或者有什么黑科技，就完全可以做到数据被条带以后依然跟原始数据一样具备同样的压缩率。如果真有这种黑科技，那这个实验就纯粹是浪费时间了。
以上三点就是这个实验做不到完备的地方，如果你看到这儿已经觉得这实验没意义了就可以直接右上角了。老实说，我开始实验以后也犹豫过是否有必要发个帖子把结果呈现出来。想了想，这也不是什么亏心事，发出来也没什么不好意思；就算结论不可靠，也许可以起到抛砖引玉的效果；对个人来说，正常使用的规模也就如此，那么这个结果也能反映出一些现实情况了。
接下来开始正文。
如题目所示，本文的实验对象是Intel 520 SSD，当然，两块，不然没得条带。
实验的方式是用一组可压缩数据数次写入进这两块520组成的RAID 0分区里。这组数据是903个TGA格式图片（类似于BMP格式，只要像素数和色深固定，文件大小就一样），共4.11GB。因为这个数据量太小，所以由18份组成一组，这样一组数据就有74GB大。这两块520通过RST控制台创建再删除的方式分别组成条带大小不同的数个RAID 0阵列，然后用Windows磁盘管理分区并格式化，再用准备好的数据写入。为了尽可能精确，连续写入6组之前准备好的数据。以填满两块240G 520组成的RAID 0。
每次组建好RAID 0，在写入之前用CDI截取当前SMART数据，在写入完毕后再用CDI截取SMART，以此计算每次写入量。
实验开始，首先是单盘作为对照。
写入开始前。因为两块盘都是新买的，所以就只发其中一块（A盘）的了，另外一块（B盘）做了一些准备工作。在初始化并分区之前，两块盘的F1都是0，格式化后增加到2。
写入结束后，F1增大7117，F9增大158，WA为0.71。
第一个RAID 0，4KB Strip。
系统在3块盘的RAID 0里，测试数据也在这里。新建的RAID 0除了条带大小为4KB以外，其他都是默认。
A盘，第一组RAID 0写入开始前。由于重新分区格式化，F1又增加了2。
B盘，第一组RAID 0写入开始前。因为做过一些预先测试，所以写入量不是0。
A盘，第一组RAID 0写入结束后。F1增大7117，F9增大158。
B盘，第一组RAID 0写入结束后。F1增大7117，F9增大159。
后面的数据不再单独贴图并给数据了，一并用表格说明。
在解释数据之前说一下我做这个实验的目的。
一个整体可以被压缩的数据，在分段以后是否依然可以被压缩？逐个分段压缩的平均压缩率是否跟一个整体的压缩率一样？
以文件的尺度来说，在我实验中的TGA图片，每个都可以被压缩，但压缩率不尽相同，因为画面复杂度不同。全部903个文件一起用zip压缩，压缩率是51%。每张图片各自分别压缩，就会出现压缩率高于51%的，当然也会有低于51%的。这903个zip压缩文件的总体积要比1个包含903张图片的压缩文件的体积要大，因为每个压缩文件都要有文件头/尾和字典，这就是额外开销。
如果把每张图片想象为条带，那么每个条带也会有类似表现。我的猜想是，如果条带大小足够低，那么条带数据中的可压缩内容相对就少，使得开销所占比例增大，也就使压缩率(WA)变大。反之，当条带大小大到一定程度后，条带个体差异就会降低，开销所占比例也会降低，压缩率(WA)也会趋近于非条带情况。关键就在于条带大小的“拐点”在哪里，有可能即使最小可用的4KB Strip也在这个拐点之上。当然还有可能DualWrite技术足够黑科技，能够抹消条带的影响，使WA没有显著变化。
从我的测试结果上看，每一组的ΔF1和ΔF9差异都在±1，不能确定是实验误差还是实验设计的问题。因而WA的数值变化也就没有实际意义，如果保留小数不够多的话，会是完全一样的结果。
所以我的测试结论是，在这个测试尺度下，条带对Intel 520这块SSD，或者说对SF-2281主控的DualWrite数据压缩技术来说没有影响。不管你用RST组RAID 0，条带大小是4KB还是128KB，都不影响数据压缩功能的实用。所以，有RAID 0需求的，又少了一样可以纠结的东西，可喜可贺~
后记
这两块盘当然是新买的，但这个实验只是顺带着做而已，完事以后拆开，一块给服务器扩容数据存储卷，一块替代日用主机上的RAID 0用。这此的规模比当年那个测试（http://bbs.pceva.com.cn/thread-96023-1-1.html）小多了，不过出发点是一样的，那个是验证主板RAID 5能跑过千兆网，这个是验证RAID 0后会不会丢掉压缩特性。
我的本意是想通过这个测试能得到条带会影响压缩能力，以此劝阻一些人组RAID 0。结果虽然没能达到预期，但也是在意料当中，毕竟实验条件十分有限。
SF-2281主控的全盘trim时间真是太久了。写入数据的时候还有进度条可以看，每次分完区格式化可只有鼠标在转圈。要知道，组RAID 0以后这个时间也是翻倍的，但写入速度并没翻倍……所以不要脑残给SF-2281的盘来手动trim；忍不了等待就别组RAID 0；你的带宽需求达不到，组RAID 0也没用。
我当然把壳给拆了，结果其中一块盘有6颗ME2，其余全是ME3。也就是说一块是全ME3，一块是ME2和ME3的混血。谁说ISN最后三位是CGN的就是ME2颗粒的？
据小道消息称，Intel这回是真的清仓大甩卖，最后就剩这些板子（520的PCB板）了。日后即使颗粒有的是，也不会再继续造520了。在IMFT的3D-NAND没投入量产之前，Intel的消费级主力是20nm颗粒的产品。
本次测试两块盘都写入了1.5TB数据，实际的NAND写入都是900GB多，消耗了不到4个PE……
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有帐号？注册
x
评分
-
查看全部评分
|
收藏
转播
