刚看到一则新闻，说是腾讯云丢了某个客户的数据，原因是硬盘bug导致“写进去的数据读出来并不是之前写入的数据”，当然，不管具体是不是这个原因，详情如何，不做评论。本次冬瓜哥就来聊聊这个数据静默损毁（silent corruption）的一系列底层知识。
本文就是对静默损毁做简要总结性介绍。静默损毁大概有几种方式：
parity error 每个扇区都会有ecc校验区，硬盘写入数据之前会计算ecc，并在读出数据之后自行校验。按理说这样应该不会静默损毁？不是的。如果host端发给硬盘的数据已经是错的了，那么硬盘就不会知道。所以，人们使用DIF（Data Integrity Field）来实现上层的校验，也就是说，硬盘上位角色（比如HBA，或者应用）主动校验数据并将校验码写入另外的8字节中，随着512字节的扇区数据一起下发给硬盘。
DIF中可以完全自定义，也可以按照T10标准，DIF中放置扇区号、校验码和应用自定义信息。为何要放扇区号？这个下面再说。但是即便是有DIF，也无法保证从应用生成数据，到数据写入硬盘一整条路径上都不出错，有些厂商也在致力于从数据一生成的时候就时刻跟着校验，这个可以在应用层来透明的做。
2. paritial write。这个现象是由于硬盘在写入数据时，只写了一部分扇区数据，而另一部分没有写入。硬盘一般会保证扇区粒度的原子写，但是由于种种不可知因素，这种partial write也会发生，最终读出数据时多半会发现校验出错，从而报告。
此时上层程序可以从副本中读出正确的数据，多个副本同时出错的概率非常低。这个不属于静默损毁。在Raid系统里，一个条带没有完整被写完前就掉电了，也称为partial write，这个可以通过日志或者标记条带完整性来解决，不是什么大问题。
3. write lose。这个现象是说硬盘本该写入某个扇区，但是最终根本没有写入，目标扇区数据依然是老数据。这个现象会导致静默损毁，导致应用读出了旧数据，或者其它应用之前保存的完全不相关的数据，直接现象肯能是乱码之类。
这个问题可以通过在应用层做标记的方式解决，比如应用给每个数据块记录一个时间戳，如果发生了lose，则时间戳一定对不上，于是就可以判断出来。这些应用层标记可以记录在DIF 8字节里的应用自定义区域。除了数据库这种对一致性要求非常完备的系统，其他应用一般不会这么严格，所以一旦发生这个问题，只能事后恢复，比如从多个副本中再提起一遍数据做比对。无法做到事前预防。
4. mis-redirect write。这个现象是硬盘本应写入A扇区，却由于不可知原因写错了地方，写到其他扇区去了。这个问题的原因可能是host端传的扇区地址指针中某个或者某几个bit发生了畸变（比如SRAM中的互锁晶体管受到各种电离辐射粒子流轰击，直接导致状态改变）。
这种静默损毁的后果更严重，不但本次I/O对应的扇区没被更新，而且还破坏了其他扇区。这种损毁，也需要靠DIF中的应用自定义区段才能解决，但是这个代价太高昂，因为应用每读出一个数据块就要做DIF判断。
