Asgard 4T SATA SSD 狗东上车记录&测评

markdown ## 引言 最近因为网课消息闭塞的我于4月13号凌晨突然看到群友说要开车。  然后打开才知道是JD的阿斯加特4T ssd，不是深夜开的那种车，虽然2000r/4t的确是很香吧……一看就知道是灵车，作为资深灵车受害者我必须得上一上 于是整了一个  不要在意三块，另外两块是别人的（ 到货之后拍了两张序列号当保修留底，盒子没什么特别的，没有拍的欲望。 测试环境记录： > OS：Windows 10 2004 > Motherboard：ROG Z370i > CPU：Shitel 8086k > Ram：32G@3100MHz > 系统盘：760p 512G ## 跑分 先进行一下例行的跑分： 没啥区别，忘截图了，过。 ## 测试 因为这次的车非常的大，又非常的灵，让我有一种小孩开大车的感觉，所以干脆测试地彻底一点，按评(虐)测(待)的标准来。 然后打开我心爱的HDTune Pro……不对，HDTune不支持200G+的文件，我还是用 dd for Windows 自己写个脚本来测试吧。 然后让我们先用大文件读写个半盘并记录数据：  这个……明显是全盘slc擦(ca)车(che)，平时体验不错，能用能用（五毛一条，发时删除）。  暂且不谈缓外60M直接吓得我停了测试，读的那四个在底部的点是怎么回事呢？是坏块，当读到的时候系统报错数据错误无法读取，然后四个文件就这样阵亡了…… 有SMART为证（图中框出来的A1项是出厂坏块数，A6项是目前坏块数，差值即为当前坏块）  所以这四个文件就直接光荣了……  当然，这里还不能让我停下，因为只要我不停下，道路就会不断延申—— 列文虎克附体的网友们可能已经发现了，上面的smart信息里面竟然有tlc和slc写入量，经过简单的测试发现他们确实于实际数据存在关联，这么良心的固件可是绝无仅有，于是我很快地写了个脚本监测smart F9(TLC写)和FA(SLC写) 在把它放置12小时之后的半盘情况下又跑了个小粒度的测试：  可以看出来，平均50M的速度应该也有Cache正在升维有关，这个固件真的就是**有多大空，擦多大车**，这么实在的玩意自从OCZ凉了之后都没见过了。 同时，依赖于对其写入了的监控，我们可以知道，这个固态具体的擦车行为应该是：先擦满，然后边放边擦，不愧是大车。 有一说一，看这个tlc cache的斜率，自从开始上升之后全程无变化，我甚至怀疑新数据只进slc，后面写入变慢是因为要等slc缓存整进tlc去。但是因为记录数据的时候时间轴记录的不是很统一，没法给出这个猜想的证明了。  最后再来个传统艺能，IOmeter的4K random离散度测试：  WOW~ Awesome！，可以说是很稳定的烂了。 对了，最后一段的点都在0上是因为它……掉盘了，虽然重启就又能识别到盘了。  ## 总结 废物，数据的坟场，连游戏盘都不配。 ## 后续 退了