隨著Raid技術(shù)的發(fā)展，存儲的性能和安全性都有了很好的保障。對于中小項目常用的Raid5(包括Raid5e，Raid5ee和Raid6)這種級別的Raid，都能保證在1-2塊磁盤/FLASH出現(xiàn)故障的情況下，保證數(shù)據(jù)的完整性，但Raid5的保護機制是否能完整的保護數(shù)據(jù)，答案卻是否定的。

Raid5和6陣列對于普通的磁盤故障有很好的糾錯能力，但對于儲存的底層故障，Raid5和6都無法進行糾錯恢復(fù)。

硬件RAID的缺點：可以檢測并嘗試恢復(fù)Noisy Error(我們常見的磁盤損壞包括Bit Rot(磁道退化等)就是代表性的顯性錯誤(Noisy Error)，但是無法檢測到隱性錯誤(Silent Error)。常見的儲存底層隱性錯誤有以下幾種：

Phantom writes “幻影寫入”。磁盤已經(jīng)發(fā)出指令寫入磁道，由于內(nèi)部故障，并未寫入成功，但在儲存表象為寫入完成的狀態(tài)。

Misdirected reads or writes 誤讀寫。舉例：數(shù)據(jù)要在01扇區(qū)進行讀寫，卻在02扇區(qū)做了這個操作，導(dǎo)致數(shù)據(jù)混亂。

DMA parity errors DMA傳輸過程中發(fā)生的error。

Accidental overwrites 在頻繁的Swapping(文件交換)中數(shù)據(jù)誤讀寫。

隨著儲存設(shè)備技術(shù)的進化，上面這四種只是常見的Silent Error，當然會有其他更多的種類，涉及到很多底層的技術(shù)。

我們遇到的VDD Error就是屬于可以檢測并嘗試恢復(fù)Noisy Error，但是無法檢測到Silent Error，所以故障層面只顯示統(tǒng)一的VDD錯誤，但底層的故障卻不一定是相同的。

對于硬件Raid來說，在陣列卡和光纖卡的級別，它并不會去確認故障是哪一種error，這是硬件Raid先天的硬件特性限制。

我們可以看看下面這個例子，設(shè)備為IBM 5020儲存陣列，做了RAID6，并劃分了LUN。在故障的表現(xiàn)層面，磁盤陣列柜的硬件并未出現(xiàn)故障告警，在Storage Manager管理監(jiān)控軟件日志可看到:

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

等等這些出現(xiàn)VDD錯誤告警，在告警之后又進行了修復(fù):

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開始修復(fù)的動作。當VDD Repair到一定程度，完全無法repair的時候，才會表現(xiàn)為服務(wù)器告警(故障燈亮)。

但由于底層故障是Silent Error，不可避免的會有幾率出現(xiàn)hantom writes 或Misdirected reads or writes 讀寫誤載 這些Silent Error，這些錯誤導(dǎo)致的結(jié)果就是錯誤的數(shù)據(jù)被相互校檢到Raid5的其他盤了，這在硬件Raid屬于不可勘測的部分(當然在超高端的儲存設(shè)備還是有這些檢測的機制)。

在更換了故障的磁盤之后。我們回到Storage Manager的日常event，從中可以看出：

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

(在更換了新硬盤之后進行陣列重建，發(fā)生了不可恢復(fù)的錯誤，Unrecoverable read error，這種是最容易出現(xiàn)的故障。)

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

(陣列重建失敗。已經(jīng)出現(xiàn)數(shù)據(jù)丟失，輕微的數(shù)據(jù)丟失可能只是部分文件，嚴重的會導(dǎo)致整個陣列數(shù)據(jù)錯亂。)

像上面這種例子的故障，在近幾年的儲存故障發(fā)生得越來越頻繁，一方面由于儲存容量的翻倍提升帶來的磁盤/FLASH密度高速增減，另一方面不斷下降的成本也導(dǎo)致陣列磁盤感覺不如原來的穩(wěn)定了。

所以Raid5(e、ee、raid6)級別的這種陣列技術(shù)，并非在單盤雙盤損壞的情況下都能保持良好的重構(gòu)工作。在一些數(shù)據(jù)安全需求高、成本又受限的地方，我們不能只依靠Raid5的技術(shù)來規(guī)避數(shù)據(jù)丟失。

ZFS(包括raid-z技術(shù))文件系統(tǒng)的成熟，在系統(tǒng)層面能很好的補充硬件Raid的這種不可規(guī)避的數(shù)據(jù)丟失情況，所以在每個項目的規(guī)劃初期，應(yīng)該要規(guī)劃好相應(yīng)的系統(tǒng)和文件格式。