企业级的硬盘中有个功能, 经常被缩写成E2E/DPP/PI，很难从缩写推出他的本意- End to End data protection / Data Path Protection / Protection Information，即使这里写出了原文，可能还是会有“这些词我都认识，但是它到底在保护什么？”的感慨。且听笔者细细道来。
作为一个硬盘/SSD，数据安全肯定是第一位的，数据保护包括哪些功能呢？
1. 首先数据放在Flash里面，是会发生比特翻转的，所以所有的flash控制器，都会设计有flash数据纠错的ECC引擎，常见的有BCH, LDPC什么的。不管什么方法，有一点都是相通的：使用ECC引擎生成原始数据的校验码，一起放到Flash里存着，读的时候解码，纠正若干比特的错误。
假设一个ECC能力不够，Flash出错容易导致原始数据恢复不出来，那么SSD会给Host回复一个读出错，然后Host会相应处理。
普通的消费类SSD一般也就到做这里了。
2. 上述情况下，假如数据恢复不出来了，host还是会不高兴。SSD说，那我给你增加一个RAID功能吧。
多使用1/n的flash, 可以在一个条带里恢复出一个数据错误。这个大家应该也都很熟悉了，不细说了。
高端的消费类SSD和低端企业级SSD，一般做到这里。
3. 看完了Flash端的保护，数据就真的安全了吗？我们来看看完整的SSD数据链路，数据都流过了哪些地方。
Flash 上会出错，硬件上的其他地方一样会出错，只是概率大小的问题。半导体自己本身就有失效的情况，再举个极端点的case,哪个宇宙射线刚好命中你的硬盘，DUANG一下，你在缓存DDR里面的User data没准就变成Usfr Data了。这种情况更加致命。错误的Usfr data极大概率会被正确的保存到Flash里，再正确的解码，一路正确返回到Host处。这就是传说中的Silent Error，静默错误。假设银行里记录你的存款的数据100W莫名奇妙1变成0了，你说要不要抓狂？这这种静默错误，假如Host没有实时的去做各种校验，他是完全意识不到的！
我们知道一般服务器用的是ECC内存，就是为了避免DDR出错的情况。ECC-DDR内存，通常采用8+1=9颗内存的形式做冗余，可以纠正1bit的内存错误。
SSD控制器中也可以采用类似的设计，把各种DMA上的DATA FIFO, DDR，这些片内片外的大容量缓存都通过增加冗余空间/增加DDR数量保护起来。任何正常的FW/DMA操作都会经过ECC校验，有错直接自动纠错恢复。
Memblaze PBlaze系列SSD使用的控制器就具备了这样的能力，保障了数据在SSD内部各种缓存(DDR/SRAM)中不会出错。
高端企业级SSD贵就贵在这些小细节，用户可能根本感知不到这些能力，但是他们就这样默默的在后台保护你的数据安全。
4. 让我们继续严谨的追踪任何数据出错的可能性。我们知道数据存放在SSD中是由固件管理的。管理过程中不可避免需要在主控CPU中进行计算，计算结果会暂存在CPU寄存器中。那么CPU计算单元偶然算错了怎么办？（大名鼎鼎的Intel桌面CPU奔腾就干过这事）CPU寄存器被射线打到了出错怎么办？
此种错误明显比上一条中的各种缓存错误小很多，首先芯片上的面积就决定了概率，还是举射线的例子，各种缓存SRAM/DDR, 那么多门，总比寄存器那几个DWORD容易被射线照到吧。
但风险还是有，并且危害依然大概率是Silent Error。
比如说Host想读LBA a的数据，本来存在flash A位置，但是计算/FTL映射错误读到了flash B, 数据读出来通过了缓存里的层层校验，送到host端，DUANG！
这个时候，就需要End-to-End 出马了。
End to End Data protection的关键点，就是在前端input/output DMA上，Input DMA要有能力在数据进入的时候计算Protection Information （PI），该PI数据每个host LBA sector都有一份，8个Byte，也就是一共SectorSize +8=520B的数据从头到尾存放在SSD内部的生命周期里，当数据送出给Host的时候，需要在Egress DMA里对PI值进行反向运算检测错误。这样不管数据在SSD上发生了什么错误，是缓存错了几个bit，还是干脆读错了LBA都可以被检查出来，汇报给Host出错了
PI段的定义遵循SCSI协议，格式如下。
CRC管数据一致性，Reference tag避免张冠李戴，Application tag是host 用的。
特别要注明的是，在Egress DMA里做检测并去除PI，只可以保证SSD不出现Silent Error, 但是并不能纠正错误，所以和上一条中所说的缓存ECC是互补关系，当然是能纠错最好了，检错即使检出了，数据依然丢失了。
5. 看到这里，读者很容易注意到，数据进入SSD后看上去安全了，但是在Host和SSD之间并不安全啊，各种传输bus上错了怎么办？或者在Host上错了怎么办？没错，PI并不是一个只在SSD内部存在的概念，一并可以沿用到Host端。
只要Host支持PI，完全可以在上层主动附加PI, 收数据时check PI。
Nvme协议则详细定义了使用规范：
a. 按照PI的存放位置分为extend(PI和User data 挨着放，可放头，可放尾) 和separate(PI和Userdata 分开放）
b. 支持512, 512+8, 4K, 4k+8, 还允许host还有额外的8B meta data，即512+16和4K+16的sector格式
c. 目前linux kernel 4.9中Ref tag是LBA的低32位地址。但如果客户需要，根据NVMe协议 Ref tag也可以被指定传输其他信息，用户可通过修改kernel实现。
d. 按照SSD的行为，可以给每个Namespace配置：
a) Host传PI或者 PI+meta,
b) Device 生成 PI 域
c) Device 可以check或不check PI 域等多种行为组合，
上面在第4条里面介绍的SSD内部添加/检查PI是标准PI的一个子集行为。
e. 没写过/trim过的LBA，PI全1，跳过检查。这样，只要使用支持PI功能的SSD, 配合适当的host 软件/驱动，就能实现存储全路径端到端的数据检查啦！
最后总结一句：
硬件一定有几率出错，企业级SSD通过E2E可以检查到错误避免静默错误，主控内部的各种ECC能尽最大能力恢复数据，但为保数据不丢失，多备份才是王道。