nvme1.3 学习笔记 8 End-to-End Data Protection(Optional)

End-to-End Data Protection(Optional) E2E用来提供从应用程序到存储媒体再到应用程序自身的健壮的数据保护。如果这个可选机制被使能了，额外的保护信息(如:CRC)被添加到了Logical Block上面，这些保护信息被Controller或者Host用来判断本段Logical Block的完整性。额外增添的保护信息根据Namespace被格式化的方式决定被放在Metadata的前8个字节还是后8个字节。 对于超过8个字节的Metadata格式，如果保护信息包含在Metadata的前8个字节，那么CRC不会覆盖任何的Metadata字节。如果保护信息包含在Metadata的后8个字节，那么CRC会覆盖除去最后8个字节的所有的Metadata字节。 像8.2描述的，Metadata和Hence这些保护信息可能被配置为和Logical Block连续存放或者单独存储在另一块buffer上。 企业中实现的最普遍的数据保护机制是SCSI的保护信息，普遍微微两种，DIF和DIX。两种机制的主要不同是保护信息的存放位置不同。在DIF中，保护信息是和Logical Block Data连续存放，创建了一个额外的Logical Block。然而在DIX中，保护信息的存储在额外的区域。该规范定义的E2E数据保护在功能上兼容DIF和DIX。 NVMe接口支持和DIF相同的E2E保护类型。当Namespace被格式化的时候去选择这种类型(Type1,Type2,Type3)。 保护信息的格式如图254，包含在与每个Logical Block相关联的Metadata中。Guard字段包含了覆盖Logical Block 数据的CRC-16的计算。Allpication Tag对于Controller来说是一个不透明的未知数据。Reference Tag是Logical Block Data和地址联合的信息，防止Logical Block的错误定向和无序传输。和Application Tag一样，Reference Tag也可能用于保护信息的非使能检测。 Figure 254:保护信息格式   7 6 5 4 3 2 1 0 0 Guard 1 2 Application Tag 3 4 Reference Tag 5 6 7 8.3.1 The PRACT Bit 保护信息伴随Read和Write命令去执行。通过命令中的Protection Information Action(PRACT)位来控制。 8.3.1.1 Protection Information and Write Commands 图255提供了一些保护信息被伴随着Write命令被处理的例子。 如果namespace没有被格式化成带有E2E数据保护的格式，则data和metadata传输时不存在保护信息的处理。 如果namespace被格式化成了带有保护信息格式而且PRACT被清为0了，那么这些包含了保护信息和可能包含有附加Metadata的Logical Block Data和Metadata，都被从Host传输向NVM(例如：Metadata字段在Host内存和NVM中都保持着相同的大小)。当Logical Block Data和Metadata经过Controller时，这个保护信息将会被检查。如果保护信息检查出了错误，那么这个命令将会被返回一些检测到错误的状态(例如：End to End Gurad Check，End to EndApplication Tag Check或者End to End Reference Tag Check)。 如果namespace被格式化成了带有保护信息格式而且PRACT被置为1了，那么：          1.如果Namespace被格式化成Matadata 大小等于8Byte(参见图110),然后这个Logical Block Data从Host的内存被传输到Controller。当这个Logical Block通过Conteoller时，Controller应当在Logical Block Data的末尾产生并附加上保护信息，这个保护信息和Logical Block Data将会被写入到NVM(例如：Metadata不在Host的内存中)。          2.如果Namespace被格式化成Metadata大小超过8Byte的，然后这个Logical Block Data从Host的内存被传输到Controller。当这个Logical Block通过Conteoller时，Controller应该重写覆盖Metadata中的保护信息。这个Logical Block和Metadata会被写入到NVM中(例如：Metadata将会在NVM和Host的内存中保持一个相同的大小)。保护信息在Metadata中的位置会在格式化Namespace的时候被设置(参见图109的DPS字段)。 8.3.1.2 The PRACT Bit and Read Command 图256提供了一些保护信息被伴随着Read命令被处理的例子。 如果namespace没有被格式化成带有E2E数据保护的格式，则data和metadata传输时不存在保护信息的处理。 如果namespace被格式化成了带有保护信息格式而且PRACT被清为0了，那么这些包含了保护信息和可能包含有附加Metadata的Logical Block Data和Metadata，都被从NVM传输向Host内存(例如：Metadata字段在Host内存和NVM中都保持着相同的大小)。当Logical Block Data和Metadata经过Controller时，这个保护信息将会被检查。如果保护信息检查出了错误，那么这个命令将会被返回一些检测到错误的状态(例如：End to End Gurad Check，End to EndApplication Tag Check或者End to End Reference Tag Check)。 如果namespace被格式化成了带有保护信息格式而且PRACT被置为1了，那么：          1.如果Namespace被格式化成Matadata 大小等于8Byte(参见图110),这个Logical Block和Metadata被Controller从NVM中读取。当Logical Block和Metadata通过Controller时，保护信息将会被检测。如果保护信息被检测到了错误(例如：End to End Gurad Check，End to EndApplication Tag Check或者End to End Reference Tag Check)。当处理完这个保护信息之后，Controller会将他从数据中剥离并将Logical Block Data传输到Host(例如：Metadata是不放在Host内存中的)。          2.如果Namespace被格式化成Metadata大小超过8Byte的，然后这个Logical Block Data被Controller从NVM中读取。当这个Logical Block通过Conteoller时，Controller应该检测嵌入到Metadata中的保护信息。如果保护信息检测失败了，Controller将会返回一个错误的状态(例如：End to End Gurad Check，End to EndApplication Tag Check或者End to End Reference Tag Check)。当保护信息被处理之后，Controller会把Logical Block Data和Metadata发送向Host(例如：Metadata将会在NVM和Host内存中保持相同的尺寸大小)。 8.3.1.5 Controller of Protection Information Checking-PRCHK 保护信息的检查通过Controller进行以下几种操作组成。 如果Protection information Check(PRCHK)字段的Bit2位被设置为1，那么Controller应该去比较保护信息的Guard字段和Logical Block Data计算出来的CRC16. 如果Bit1位被设置为1，那么Controller应该比较保护信息中Application Tag的unmasked的位和命令中的Logical Block Application Tag(LBAT)字段。如果命令中的Logical Block Application Tag Mask(LBATM)字段被清为0了，那么相应的保护信息的Application Tag字段应该被mask。 对于Type1保护，如果PRCHK字段的bit0被设置为了1，那么Controller应该比较保护信息中的Reference Tag位和计算出来的Reference Tag。