使用 mdadm 檢測和糾正位腐爛
我即將在我的家庭 linux box nas 中重新組織我的所有硬碟驅動器，並希望使用 mdadm raid 進行數據保護及其用於重塑陣列的靈活性。但是，在我為此使用 mdadm 之前，我想知道它如何處理bit rot。特別是不會導致從 HDD 發送不可恢復的讀取錯誤消息的位損壞類型。
鑑於我可能會在 nas 的 8 個磁碟中使用至少 21TB 的 HDD 以及關於 HDD故障機率的各種報價，我認為在從單個磁碟故障重建期間，我很可能會遇到剩餘磁碟上的某種形式的位腐爛。如果其中一個驅動器出現不可恢復的讀取錯誤，驅動器實際上將其報告為錯誤，我相信 raid6 應該沒問題（是嗎？）。但是，如果從磁碟讀取的數據是錯誤的但磁碟沒有報告這樣的數據，那麼即使使用 raid6，我也看不到如何自動更正。這是我們需要關心的事情嗎？鑑於文章It is 2010 and RAID5 still works，以及我自己在家庭和工作中的成功經驗，事情並不一定像流行語和市場行銷讓我們相信的那樣悲觀，但我討厭僅僅因為 HDD 出現故障而不得不從備份中恢復。
鑑於使用模式是，最多寫入幾次，偶爾讀取，我需要執行數據清理。我在 archlinux wiki上看到了用於數據清理數組 的 mdadm 命令
echo check > /sys/block/md0/md/sync_action然後監控進度
cat /proc/mdstat在我看來，它將讀取所有磁碟的所有扇區並檢查數據是否匹配奇偶校驗，反之亦然。儘管我注意到文件中非常強調說在某些情況下“檢查”操作將無法自動更正，只能檢測，並且它會留給使用者來修復。
我應該選擇什麼 mdadm RAID 級別來最大限度地防止位損壞，我應該執行哪些維護和其他保護步驟？這不能保護我免受什麼傷害？
編輯：我不打算開始 RAID vs ZFS 或任何其他技術 QA。我想具體了解 mdadm raid。這也是我在 Unix & Linux 而不是SuperUser上詢問的原因。
編輯：答案是： mdadm 只能糾正磁碟系統在數據清理期間報告的 URE，並在清理期間檢測靜默位腐爛但不能/不會修復它？
坦率地說，我發現您拒絕 RAIDZ2 ZFS 是相當令人驚訝的。除了它不是 Linux MD之外，它似乎幾乎完美地滿足了您的需求。我不是為了將 ZFS 推向大眾，但一個簡單的事實是，您的問題是 ZFS從頭開始設計來解決的問題之一。依靠 RAID（任何“正常”RAID）在減少冗餘或無冗餘的情況下提供錯誤檢測和糾正似乎是有風險的。即使在 ZFS 無法正確糾正數據錯誤的情況下，它至少可以檢測到錯誤並讓您知道存在問題，從而讓您採取糾正措施。
您不必定期對 ZFS 進行全面清理，但建議這樣做。ZFS 將驗證從磁碟讀取的數據是否與讀取數據時寫入的數據相匹配，並且在不匹配的情況下 (a) 使用冗餘來重建原始數據，或者 (b) 將 I/O 錯誤報告給應用程序。此外，清理是一種低優先級的線上操作，與大多數文件系統中的文件系統檢查完全不同，大多數文件系統既可以是高優先級的，也可以是離線的。如果您正在執行擦洗，並且擦洗以外的其他東西想要執行 I/O，那麼擦洗將在整個過程中處於次要地位。ZFS 清理取代了 RAID 清理以及文件系統元數據和數據完整性檢查，因此比僅僅擦洗 RAID 陣列以檢測任何位損壞要徹底得多（這並不能告訴您數據是否有任何意義，只是它已被 RAID 控制器正確寫入）。
ZFS 冗餘（RAIDZ、鏡像等）的優點是在清理期間不需要檢查未使用的磁碟位置的一致性；在清理期間只檢查實際數據，因為這些工具會遍歷分配塊鏈。這與非冗餘池相同。對於“正常”RAID，必須檢查所有數據（包括磁碟上任何未使用的位置），因為 RAID 控制器（無論是硬體還是軟體）不知道哪些數據實際上是相關的。
通過使用 RAIDZ2 vdev，任何兩個組成驅動器都可能在您面臨另一個驅動器故障導致實際數據失去的風險之前發生故障，因為您有兩個驅動器的冗餘價值。這與 RAID6 基本相同。
在 ZFS 中，對所有數據（包括使用者數據和元數據）進行校驗和（除非您選擇不這樣做，但建議不要這樣做），並且這些校驗和用於確認數據沒有因任何原因而更改。同樣，如果校驗和與預期值不匹配，則數據將被透明地重建或報告 I/O 錯誤。如果報告了 I/O 錯誤，或者清理髮現文件損壞，您將知道該文件中的數據可能已損壞，並且可以從備份中恢復該特定文件；無需完整的陣列還原。
普通的，甚至是雙奇偶校驗的 RAID 都不能保護您免受諸如一個驅動器發生故障而另一個驅動器錯誤地從磁碟讀取數據的情況。假設一個驅動器出現故障，並且任何其他驅動器的任何地方都有一個位翻轉：突然間，您發現了未檢測到的損壞，除非您對此感到滿意，否則您至少需要一種方法來檢測它。降低這種風險的方法是對磁碟上的每個塊進行校驗和，並確保校驗和不會與數據一起被破壞（防止諸如高速寫入、孤立寫入、寫入磁碟上不正確位置等錯誤），這只要啟用校驗和，這正是 ZFS 所做的。
唯一真正的缺點是您不能通過向 RAIDZ vdev 添加設備來輕鬆地增長它。**有一些解決方法，通常涉及像稀疏文件這樣的東西作為 vdev 中的設備，**並且經常被稱為“如果它是我的數據，我不會這樣做”。因此，如果您採用 RAIDZ 路線（無論您使用 RAIDZ、RAIDZ2 還是 RAIDZ3），您需要預先確定每個 vdev 中需要多少個驅動器。儘管 vdev 中的驅動器數量是固定的，但您可以通過逐漸（確保保持在 vdev 的冗餘門檻值內）用更大容量的驅動器替換驅動器並允許完全重新同步來增加 vdev。
這個答案是根據我發現的各種證據進行推理的產物。我不知道核心 Linux 實現是如何工作的，因為我不是核心開發人員，而且那裡似乎存在大量無意義的錯誤資訊。我認為核心 Linux 做出了明智的選擇。除非我弄錯了，否則我的回答應該適用。
許多驅動器使用 ECC（糾錯碼）來檢測讀取錯誤。如果數據損壞，核心應該從支持 ECC 的驅動器接收該塊的 URE（不可恢復的讀取錯誤）。在這些情況下（下面有一個例外），複製損壞的或空的數據而不是好的數據將相當於精神錯亂。在這種情況下，核心應該知道哪些是好數據，哪些是壞數據。根據It is 2010 and RAID5 still works …文章：
考慮一下這個替代方案，我知道它至少被幾個陣列供應商使用。當 RAID 卷中的驅動器報告 URE 時，陣列控制器會增加計數並通過從奇偶校驗重建塊來滿足 I/O。然後它在報告 URE 的磁碟上執行重寫（可能帶有驗證），如果扇區壞了，微碼將重新映射，一切都會好起來的。
但是，現在例外：如果驅動器不支持 ECC，驅動器存在數據損壞，或者韌體特別失靈，則可能不會報告 URE，並且會將損壞的數據提供給核心。在數據不匹配的情況下：似乎如果您使用的是2磁碟RAID1或RAID5，那麼即使處於非降級狀態，核心也無法知道哪些數據是正確的，因為只有一個奇偶校驗塊並且沒有報告 URE。在 3 磁碟 RAID1 或 RAID6 中，單個損壞的非 URE 標記塊與冗餘奇偶校驗不匹配（與其他關聯塊組合），因此應該可以進行適當的自動恢復。
這個故事的寓意是：使用帶有 ECC 的驅動器。不幸的是，並非所有支持 ECC 的驅動器都宣傳此功能。另一方面，要小心：我認識有人在 2 磁碟 RAID1（或 2 副本 RAID10）中使用廉價 SSD。其中一個驅動器在每次讀取特定扇區時返回隨機損壞的數據。損壞的數據會自動複製到正確的數據上。如果 SSD 使用了 ECC，並且執行正常，那麼核心應該已經採取了適當的糾正措施。