浦科特M6V小试验，覆盖、剪切能否触发Trim？

我们知道，在SSD、系统、驱动支持Trim的条件下，操作系统可以在删除文件的时候发送指令给SSD主控，以通知它哪些数据占用的地址是“无效”的，从而提升SSD的GC效率与长期使用性能。（Trim详细介绍：http://www.pceva.com.cn/topic/crucialssd/index-6_6.html）

那么在删除以外的文件剪切、覆盖写入时是否会触发Trim？今天就已浦科特M6V为例用试验来验证。

首先介绍一下SSD对于Trim支持的几个特性，包括RZAT和DRAT。RZAT和DRAT属性表达了SSD在接受Trim指令后的工作方式。在支持Trim特性的前提下，如果SSD支持DRAT特性，则访问Trim后的LBA地址的数据每次都会得到相同的内容，如果SSD进一步支持RZAT特性，那么访问Trim后的LBA地址数据不仅每次都相同，而且必定是全零。（具体内容请看一块硬盘的简历——ATA_IDENTIFY_DEVICE信息入门中的相关介绍）

如上图所示，浦科特M6V支持Trim，并且同时支持RZAT和DRAT特性，因此在Trim过后被删除文件原来LBA位置的数据将会变为全零。

接下来介绍一下本次试验使用的软件——WinHex。WinHex可以对硬盘数据进行直接编辑，可以分析文件所在的LBA位置，也可以直接跳转到指定LBA位置查看硬盘上的数据内容。在Tools菜单中选择Open Disk，选择M6V上的分区E盘，WinHex将会生成一个磁盘快照，根据盘上数据量的不同会需要等待一小段时间。

这次试验选择存储在E盘根目录的AS SSD Benchmark.exe作为试验目标，在WinHex中选中AS SSD Benchmark.exe，可以在窗口下方看到AS SSD Benchmark.exe文件在硬盘中所在的LBA首地址是00F6F59000，我们记下这个地址。除了LBA地址外，WinHex中还显示了16进制的文件内容，可以看到代表可执行文件的文件头MZ。

随后删除AS SSD Benchmark.exe，因为浦科特M6V支持Trim并且具备RZAT和DRAT特性，不出意料的话再次使用WinHex查看AS SSD Benchmark.exe原来所在的LBA位置将会变成一片全零。

在WinHex中关闭硬盘并重新打开，选择重建一个新的硬盘快照以查看硬盘上数据的最新变化，在如下对话框中点击“Take new one”。

可以看到在AS SSD Benchmark.exe原来所在的LBA首地址00F6F59000之后已经变成了全零，WinHex依然可以找到AS SSD Benchmark.exe是因为文件虽然删除，但只是对文件分配表上进行修改打上了已删除的标志，文件分配表中还有文件的信息，这也是很多数据恢复软件能够查找和还原已删除文件的原理，只不过在支持Trim的M6V上，虽然能找到原来文件的LBA地址，但文件数据已经清零，也就无法恢复文件内容了。

好了，前边我们验证了删除会触发Trim，接下来进入正题：验证文件剪切与覆盖写入是否会触发Trim，是否会影响SSD长期使用性能。

文件覆盖写入验证：

还是以AS SSD Benchmark.exe为试验目标（AS：以往是我测试别人，如今我成了测试对象，悲了个催…），重新拷贝AS SSD Benchmark.exe到E盘，新的LBA地址是04B0145000。之后用记事本新建一个文本文件，内容为“This is a test”（下边截图中是This is a text属于笔误，不影响测试过程），然后另存为AS SSD Benchmark.exe，当然了，这是一个用文本文件更改扩展名伪装出来的假EXE文件，只是为了进行文件覆盖写入的试验。将这个30字节的同名AS SSD Benchmark.exe文件复制到E盘，并选择覆盖写入：

接下来在WinHex中重新载入E盘，建立新的硬盘快照，可以看到AS SSD Benchmark.exe的LBA首地址已经不再是04B0145000，而是变为新的位置0001161000。文件头FFFE表示这是一个Unicode文本文件，虽然挂了一个.exe的扩展名，但记事本保存的文件头还是会暴露出他的真身。

这次覆盖写入的同名文件存放到了新的LBA位置，那么原有LBA位置的数据是否被Trim掉了呢？使用WinHex查看原有LBA位置04B0145000的内容可以看到已经变成了全零：

由此可见，在文件系统层面上，对同文件名文件的覆盖写入会将文件数据写入到新的LBA位置，然后删除原有文件内容，同样触发了对原有文件的Trim。

文件剪切验证：

延续上边测试中的文件，我们将30字节的AS SSD Benchmark.exe假文件剪切到其他硬盘当中，与很多人预想的相同，剪切基本等同于复制后删除，同样触发Trim，原有LBA位置0001161000后的数据已经被清零：

通过以上试验我们验证了同名文件覆盖写入以及剪切操作都会触发Trim，浦科特M6V对于Trim指令的GC响应也十分迅速。

这是M6V的新特性？其他的ssd不支持？

样本能不能多几个，不同SSD可能不一样

ChineseBoy 发表于 2015-9-21 11:53
这是M6V的新特性？其他的ssd不支持？

并非M6V专属，只要SSD支持Trim，并且同时支持RZAT和DRAT特性就可以达到同样的效果。这里只是以M6V为例进行的测试

PLEXTOR的TRIM一直很积极。

找个ARC100测，结果估计就欢乐了

感觉上还是SF的适时GC最有谱，比空闲GC或者全局主动GC少要求TRIM的准度

ARC100路过。。。。

nighttob 发表于 2015-9-21 19:38
找个ARC100测，结果估计就欢乐了

貌似不支持DRAT和RZAT，用TrimCheck只能得到不确定的结果

顶楼RZAT和DRAT的解释是否反了？
Determinated Read After Trim
Read Zeros After Trim

好文章，通俗易懂，科普的很到位。请问主编大大，WinHex这个工具软件能在windows server 2008 R2环境下正常使用吗？我想测一下坑屎盾V200的Trim功能是否很及时，麻烦能否和我分享一下你那个官方原版无毒的WinHex

= =这样的话SSD岂不是不能误删文件了

脑浆断层现象 发表于 2015-9-28 08:20
= =这样的话SSD岂不是不能误删文件了

确实啊，这岂不是意味着一旦错误操作，后果很严重。