☰

為什麼 mdadm 無法處理「幾乎失敗」的磁碟？

tag-icon • tag-icon storage mdadm
為什麼 mdadm 無法處理「幾乎失敗」的磁碟？

在我的職業生涯中，我曾多次在各種環境（例如CentOS/Debian 機器、Synology/QNAP NAS）中遇到mdadm RAID 集（RAID1+0、5、6 等），它們似乎根本無法處理故障磁碟.該磁碟並未完全失效，但有數以萬計的壞扇區，並且根本無法處理 I/O。但是，它並沒有完全死亡，它仍然在工作。內核日誌通常會充滿 UNC 錯誤。

有時，SMART 會將磁碟識別為故障，有時除了 I/O 緩慢之外沒有其他症狀。

緩慢的 I/O 實際上會導致整個系統凍結。透過 ssh 連線需要很長時間，webGUI（如果是 NAS）通常會停止運作。透過 ssh 運行命令也需要很長時間。直到我斷開/故意將磁碟從陣列中“故障”出來，然後事情就會恢復到“正常” - 這與降級陣列一樣正常。

我只是想知道，如果磁碟讀取/寫入需要很長時間，為什麼不將其從陣列中剔除，在日誌中添加一條訊息並繼續？這似乎讓整個系統陷入癱瘓，因為一個磁碟有點奇怪，完全抵消了使用 RAID 的主要好處之一（容錯 - 在磁碟發生故障時繼續運行的能力）。我可以理解，在單磁碟場景中（例如，您的系統連接了單個SATA 磁碟，並且無法正確執行讀取/寫入），這是災難性的，但在RAID 集（尤其是容錯“個性”）中，它看起來不僅令人討厭而且違背常識。

mdadm 的預設行為基本上會削弱該盒子，直到有人遠端登入並手動修復它，這是否有充分的理由？

答案1

一般來說，目的是襲擊，根據所選的Raid級別，在關鍵目標之間提供不同的平衡 資料冗餘, 可用性, 表現和容量。

根據具體要求，儲存所有者的責任決定各種因素的哪種平衡對於特定目的是正確的，創建一個可靠的解決方案。

所選 Raid 解決方案（在本例中我們討論的是軟體mdadm）的工作首先是確保資料保護。考慮到這一點，很明顯，RAID 解決方案的工作並不是將業務連續性置於資料完整性之上。

換句話說：mdadm 的工作是避免失敗的 raid。只要「行為怪異的磁碟」沒有完全損壞，它仍然有助於襲擊。

那麼，為什麼不直接從陣列中剔除一個行為怪異的磁碟，在日誌中添加一條訊息然後繼續呢？因為這樣做會增加遺失資料的風險。

我的意思是，你是對的，在特定時刻，從商業角度來看，繼續下去似乎是更好的解決方案。但實際上，已刪除到日誌中的訊息可能仍然未被偵測到，因此 raid 的降級狀態仍然未被偵測到。一段時間後，最終同一 raid 中的另一個磁碟發生故障，導致故障 raid 上儲存的資料最終消失。

除此之外：很難準確定義什麼是「行為異常的磁碟」。換句話說：在磁碟陣列中操作的單一磁碟的可接受的操作行為是什麼？

我們中的一些人可能會回答“磁碟顯示一些錯誤”。其他人可能會回答：「只要能改正錯誤就好了」。其他人可能會回答：「只要磁碟在給定時間內回應所有命令，就一切正常」。其他人則說「如果磁碟溫度與同一陣列中所有磁碟的平均溫度相差超過 5°C」。另一個答案可能是“只要擦洗沒有顯示錯誤”，或“只要 SMART 沒有顯示錯誤”。

所寫的清單並不長，也不是完整的。

關鍵在於「磁碟的可接受行為」的定義是一個解釋問題，因此也是儲存所有者的責任，而不是 mdadm 應該自行決定的事情。

答案2

關鍵問題是，發生故障的 SATA 磁碟機有時會在其內部錯誤復原過程期間凍結整個匯流排。出於這個原因，應該使用啟用 TLER僅在 RAID 陣列（最好是企業級型號）中使用磁碟機。

SAS 硬碟受此問題影響較小，但並非完全擺脫此問題。

答案3

除了所說的之外，我還想補充一點，但這一點是重要的考慮因素。

什麼一個驅動器當扇區讀取緩慢時會發生什麼？

據推測，設計為單獨運行的驅動器（例如典型的“桌面”驅動器）假定沒有其他方法來檢索儲存在該壞扇區中的資料。他們會在很長一段時間內不惜一切代價嘗試檢索數據，一次又一次地重複。當然，他們也會將該磁區標記為失敗，因此他們會在您下次寫入時重新映射它，但您必須為此寫入。在你重寫之前，每次你從那個地方讀到的時候，他們都會感到窒息。在 RAID 設定中，這意味著 RAID 驅動器仍然可以工作，沒有理由將其踢出，但對於應用程式來說，陣列將減慢速度。

另一方面，「企業」驅動器，尤其是「品牌」驅動器，通常假設它們始終用於 RAID 設定。一個“品牌”控制器，看到“品牌”驅動器，實際上甚至可能通知他們關於 RAID 存在的韌體。因此，即使可以進行多次嘗試並讀取磁區，磁碟機也會提前停止並報告 I/O 錯誤。然後控制器就有機會更快地回复，將讀取指令鏡像到同級驅動器（並將壞的驅動器從陣列中踢出）。當你拉出並徹底探索/測試驅動器時，你發現沒有明顯的問題 - 根據控制器邏輯，它只是減慢了一會兒，這足以停止使用它。

我推測這可​​能是唯一的“桌面”驅動器與“品牌”/“企業”NL-SAS 和 SATA 驅動器之間的差異。這可能是為什麼當您購買實際上由東芝製造的“HPE”驅動器時，與購買“東芝”品牌的驅動器相比，您要支付三倍的費用。

但是，某些驅動器確實支援對此的一些通用控制。它被稱為 SCT ERC，代表SMART 指令傳輸錯誤復原控制。這是它的樣子smartctl：

不支援的

# smartctl --all /dev/sda
=== START OF READ SMART DATA SECTION ===
SCT capabilities:              (0x3037) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

支持的

=== START OF READ SMART DATA SECTION ===
...
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

如果幸運的話，您可以使用 來控制此功能smartctl。您可以檢索或設定兩個逾時，嘗試重新讀取多長時間以及嘗試重新寫入多長時間：

# smartctl -l scterc /dev/sda
SCT Error Recovery Control:
           Read:     70 (7.0 seconds)
          Write:     70 (7.0 seconds)

# smartctl -l scterc /dev/sde
SCT Error Recovery Control:
           Read: Disabled
          Write: Disabled

# smartctl -l scterc /dev/sdd
Warning: device does not support SCT Error Recovery Control command

smartctl -l scterc,120,60 /dev/sde

這意味著：十分之 120 秒重試讀取；十分之 60 秒重試寫入。零意味著「重試直到死亡」。不同的驅動器對此有不同的預設設定。

因此，如果您單獨使用「RAID 版」驅動器，最好將 ERC 逾時設為零，否則可能會遺失資料。另一方面，如果您在 RAID 中使用驅動器，最好設定一些合理的低非零設定。

來源：amarao @ Habrahabr，俄語。

PS 還有關於 SAS 的說明。使用sdparm，它支援更多對此的控制。

答案4

我曾經遇到過磁碟無法工作，但以某種方式取出控制器的情況。

從歷史上看，這在 PATA 中是可行的，其中主驅動器和從驅動器位於同一電纜上，一個驅動器發生故障可能會幹擾對另一個仍然正常的驅動器的存取。刪除損壞的驅動器可以重新啟用對剩餘驅動器的訪問，或者可能需要重新啟動電源，但 raid 可能會降級，然後可以開始恢復。

SATA 不太容易受到此影響，但控制器仍有可能受到影響。根據我的軟體突襲經驗，有更多的血淋淋的內部結構暴露出來，而這些細節可能會被更高級的專用突襲控制器隱藏起來。

我沒有在 SAS 或 NVME 中經歷過這種情況，但 SAS 通常意味著內部具有更多磁碟處理智慧的硬體 raid 控制器。

相關內容