写在DST之前
企业级SSD系统在日益变得复杂,有增强掉电保护的备电电容,有使用频率越来越高的DRAM,有堆叠层数越来越高的NAND, NAND结构的复杂对固件的要求也相应的变高,如存储单元里的数据一段时间不读会导致之后可能读不出来或者出现很多的bit翻转等等。而备电电容有老化的风险以及在不同的温度环境下会影响电容的可靠性;DRAM使用不当易出现ECC,甚至是UNC,影响盘的可靠性;NAND的上的冷数据如果不经常性的去读取就可能存在数据丢失的风险。
像服务器上电自检一样,SSD在上电过程中也会做电容,DRAM等自检操作。但是一般盘上电使用之后就极少会下电,所以为了能让HOST能实时的获取盘内部部件的情况,NVMe协议提供了一个标准的命令Device self-test来主动触发盘的部件检测,可以快速的发现盘是哪个部件出现了问题,可以相应的做出反应,保障用户数据的安全。
Device self-test
NVMe命令device self-test是一个管理类命令,定义了一个操作序列。具体内容如下:
如上图所示:每个序列都规定了相应的操作,有些操作是针对controller层级,有些操作是NVM层级。Controller层级的主要是用于测试SSD的功能是否还正常,比如电容容值检查,如果容值变低,则会影响SSD的掉电时间。
1、Device self-test命令在Command DW 10字段中定义了诊断的操作类型,而所有其他命令指定的字段都要保留。
如上图所示,目前支持的操作类型有4种,
开始一个短诊断操作;
1、短诊断的完成时间不能大于2min。
2、开始一个长诊断操作;
长诊断的完成时间由Identify Controller的字段EDSTT定义,单位是分钟。
E、开始一个厂商自定义操作;
F、中断一个诊断操作;
2、中断一个自检命令的操作有:
1、Controller reset
2、NVMe Format Command
3、一个STC为F的Device self-test命令
4、一个删除对应的ns的操作
5、Sanitize命令
3、触发自检命令之后,FW会按照相应的序列顺序执行,命令运行的情况在device self-test log中显示,这个log可通过get log page命令的LID=6来获取。
1、Current Device Self-Test Operation 表示当前的诊断操作类型
2、Current Device Self-Test Completion 表示当前的诊断操作进度
3、Self-test Result Data Structure 总共有20条记录,记录了历史的自检结果,主要关注两个点:
* Device Self-test Status:这里显示了自检的结果,成功或者失败。
* Segment Number:这里显示了失败在哪个序列操作.
DRAM Check
*由于DRAM用作用户数据的缓存,以及存放了部分代码和重要的数据,所以如果对这部分DRAM区域做读写校验的话,会直接导致数据的丢失或者固件exception。
*由于DRAM在打开ECC校验的情况下,如果出现未写先读的情况,会使得DRAM出现UNC.
基于以上两点,对于DRAM Check,固件主要要做的事情有两个:
1、对于无法做读写校验(即只读)的区域,FW需要保证该区域已经写过数据,所以可以直接去读该区域。如果出现UNC,则固件存在bug,会危及盘的正常使用。
2、对于用作堆区域的DRAM空间,可以申请出来做读写校验。除了校验数据的正确性,还需要关注DRAM是否出现ECC,如若出现ECC,则可能会危及盘的正常使用。
Volatile Memory Backup
我们常用的数据缓存介质DRAM是易失性存储介质,在设备掉电之后DRAM中的数据都会丢失。但是DRAM的数据传输速率高,为了性能考虑,其存在又是必须的。
1、缓存用户数据,加速命令的执行,减少QOS.
2、缓存了设备的元数据,加速了元数据的修改。
所以为了解决设备掉电之后缓存数据丢失的问题,设备需要增加备电电容以供在掉电时保证缓存数据存入flash。但是电容存在一定的失效率,失效的原因可能如下:
1、电容出厂时个体的差异导致能承受的电压阈值偏低;
2、随着时间的推移,电容会存在漏液现象导致容值降低。
软件需要在设备上电或者运行过程中对电容进行定时检测,以防止电容失效或者电容容值下降不足以保证设备刷新缓存数据所需时间导致数据丢失,但是电容的检测又不能太频繁。否则一是会影响电容的使用寿命,二是如果在电容放电的过程中盘掉电了,会影响盘的掉电时间。
所以Host使用device self-test命令来检查电容的容值是必需的,尤其是在接近盘的生命末期的时候,但是又不能太频繁。
Metadata validation
在SSD的所有写入数据中,存在一些频繁更新的数据和一些很久都不会更新的数据,如果那些很久都不会更新的数据量大的话,那么也会导致对应的元数据很久得不到更新。所以为了解决这个问题,在device self-test命令的元数据检查序列里,FW会去对元数据做读校验,确认元数据的完整性。
1、确保元数据还能从NAND读出来,不会出现UNC;
2、对读出来的数据做check,保证数据的正确性。
结尾
限于篇幅以及对协议的理解不同,各个厂商对其他的device self-test序列所做的事情存在区别,所以这里不再赘述。只介绍了对以上3个序列的个人理解。
原文标题:日益复杂的企业级SSD系统,如何做Device self-test?
文章出处:【微信公众号:大普微】欢迎添加关注!文章转载请注明出处。
责任编辑:haq
-
电容
+关注
关注
99文章
5993浏览量
149986 -
SSD
+关注
关注
20文章
2851浏览量
117219
原文标题:日益复杂的企业级SSD系统,如何做Device self-test?
文章出处:【微信号:dputech,微信公众号:DapuStor】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论