随着Raid技术的发展，存储的性能和安全性都有了很好的保障。对于中小项目常用的Raid5（包括Raid5e，Raid5ee和Raid6）这种级别的Raid，都能保证在1-2块磁盘/FLASH出现故障的情况下，保证数据的完整性，但Raid5的保护机制是否能完整的保护数据，答案却是否定的。

Raid5和6阵列对于普通的磁盘故障有很好的纠错能力，但对于储存的底层故障，Raid5和6都无法进行纠错恢复。

硬件RAID的缺点：可以检测并尝试恢复Noisy Error（我们常见的磁盘损坏包括Bit Rot(磁道退化等)就是代表性的显性错误（Noisy Error），但是无法检测到隐性错误（Silent Error）。常见的储存底层隐性错误有以下几种：

Phantom writes “幻影写入”。磁盘已经发出指令写入磁道，由于内部故障，并未写入成功，但在储存表象为写入完成的状态。

Misdirected reads or writes 误读写。举例：数据要在01扇区进行读写，却在02扇区做了这个操作，导致数据混乱。

DMA parity errors  DMA传输过程中发生的error。

Accidental overwrites 在频繁的Swapping（文件交换）中数据误读写。

随着储存设备技术的进化，上面这四种只是常见的Silent Error，当然会有其他更多的种类，涉及到很多底层的技术。

我们遇到的VDD Error就是属于可以检测并尝试恢复Noisy Error，但是无法检测到Silent Error，所以故障层面只显示统一的VDD错误，但底层的故障却不一定是相同的。

对于硬件Raid来说，在阵列卡和光纤卡的级别，它并不会去确认故障是哪一种error，这是硬件Raid先天的硬件特性限制。

我们可以看看下面这个例子，设备为IBM 5020储存阵列，做了RAID6，并划分了LUN。在故障的表现层面，磁盘阵列柜的硬件并未出现故障告警，在Storage Manager管理监控软件日志可看到:

     Date/Time: 15-2-6 14:39:55
Sequence number: 6806
Event type: 2014
Event category: Internal
Priority: Informational
Event needs attention: false
Event send alert: false
Event visibility: true
Description: VDD logged an error
Event specific codes: 0/0/0
Component type: Controller
Component location: Enclosure 85, Slot A
Logged by: Controller in slot A

等等这些出现VDD错误告警，在告警之后又进行了修复:

Date/Time: 15-2-6 14:39:55
Sequence number: 6805
Event type: 201E
Event category: Internal
Priority: Informational
Event needs attention: false
Event send alert: false
Event visibility: true
Description: VDD repair started
Event specific codes: 0/0/0
Component type: Controller
Component location: Enclosure 85, Slot A
Logged by: Controller in slot A

VDD Repair start开始修复的动作。当VDD Repair到一定程度，完全无法repair的时候，才会表现为服务器告警（故障灯亮）。

但由于底层故障是Silent Error，不可避免的会有几率出现hantom writes 或Misdirected reads or writes 读写误载 这些Silent Error，这些错误导致的结果就是错误的数据被相互校检到Raid5的其他盘了，这在硬件Raid属于不可勘测的部分（当然在超高端的储存设备还是有这些检测的机制）。

在更换了故障的磁盘之后。我们回到Storage Manager的日常event，从中可以看出：

Thu Feb 07 07:23:32 JST 2015  42054  Unreadable sector(s) detected- data loss occurred – vol00

（在更换了新硬盘之后进行阵列重建，发生了不可恢复的错误，Unrecoverable read error，这种是最容易出现的故障。）

Thu Feb 07 07:23:32 JST 2012  42205  Drive failed -initialization/reconstruction failure – Tray.85.Drive.04 Critical

（阵列重建失败。已经出现数据丢失，轻微的数据丢失可能只是部分文件，严重的会导致整个阵列数据错乱。）

像上面这种例子的故障，在近几年的储存故障发生得越来越频繁，一方面由于储存容量的翻倍提升带来的磁盘/FLASH密度高速增减，另一方面不断下降的成本也导致阵列磁盘感觉不如原来的稳定了。

所以Raid5(e、ee、raid6)级别的这种阵列技术，并非在单盘双盘损坏的情况下都能保持良好的重构工作。在一些数据安全需求高、成本又受限的地方，我们不能只依靠Raid5的技术来规避数据丢失。

ZFS（包括raid-z技术）文件系统的成熟，在系统层面能很好的补充硬件Raid的这种不可规避的数据丢失情况，所以在每个项目的规划初期，应该要规划好相应的系统和文件格式。