☰

如何監控 BTRFS 檔案系統 raid 的錯誤？

tag-icon • tag-icon linux raid events btrfs
如何監控 BTRFS 檔案系統 raid 的錯誤？

我看到了一些有關守護進程的文檔，該守護程序可以為各種 BTRFS 事件執行程序/腳本，但我再也找不到它了。

如何在 BTRFS raid1 陣列的磁碟機故障時執行腳本/程式？我想針對任何錯誤運行一個腳本，以作為可能發生故障的驅動器的早期警告，但實際的驅動器故障是最重要的。我想在此時卸載檔案系統（如果這不是 BTRFS 所做的）並設定警報。

答案1

除了常規的日誌系統之外，BTRFS 還具有一個統計數據命令，追蹤每個磁碟機的錯誤（包括讀取、寫入和損壞/校驗和錯誤）：

# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs   0
[/dev/mapper/luks-123].read_io_errs    0
[/dev/mapper/luks-123].flush_io_errs   0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0

所以你可以創建一個簡單的 root cronjob：

[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'

這將每小時檢查一次正錯誤計數並向您發送一封電子郵件。顯然，您將測試這樣的場景（例如透過導致損壞或刪除 grep）來驗證電子郵件通知是否有效。

此外，對於 BTRFS（具有校驗和）等進階檔案系統，通常建議每隔幾周安排一次清理，以檢測由壞磁碟機引起的靜默損壞。

@monthly /sbin/btrfs scrub start -Bq /data

此-B選項將使擦洗保持在前台，以便您可以在 cron 發送給您的電子郵件中看到結果。否則，它將在背景運行，您必須記住手動檢查結果，因為它們不會出現在電子郵件中。

更新：按照 Michael Kjörling 的建議改進了 grep，謝謝。

更新2：關於清理與常規讀取操作的附加說明（這不僅適用於 BTRFS）：
正如 Ioan 所指出的，清理可能需要幾個小時，具體取決於數組的大小和類型（以及其他因素），在某些情況下甚至超過一天。它是主動掃描，不會檢測未來的錯誤 - 清理的目標是及時查找並修復驅動器上的錯誤。但與其他 RAID 系統一樣，建議安排定期清理。確實，典型的 I/O 操作（例如讀取檔案）確實會檢查讀取的資料是否確實正確。但考慮一個簡單的鏡像 - 如果檔案的第一個副本損壞，可能是由即將死亡的驅動器損壞，但第二個副本（正確的）實際上由 BTRFS 讀取，那麼 BTRFS 將不知道存在損壞在其中一個驅動器上。這只是因為請求的資料已收到，它與 BTRFS 為此檔案儲存的校驗和匹配，因此 BTRFS 不需要讀取另一個副本。這意味著，即使您專門讀取一個驅動器上已知已損壞的文件，也不能保證此讀取操作會檢測到損壞。
現在，我們假設 BTRFS 只從好的驅動器上讀取數據，沒有運行任何清理來檢測壞驅動器上的損壞，然後好驅動器也壞了 - 結果將是數據丟失（至少 BTRFS 會知道）哪些文件仍然正確並且仍然允許您閱讀這些文件）。當然，這是一個簡化的例子；實際上，BTRFS 並不總是從一個磁碟機讀取資料而忽略另一個磁碟機。
但關鍵是定期清理很重要，因為它們會發現（並修復）常規讀取操作不一定檢測到的錯誤。

驅動器故障：由於這個問題很受歡迎，我想指出這個「監控解決方案」是用於檢測可能損壞的驅動器的問題（例如，死亡的驅動器導致錯誤但仍然可以訪問）。

另一方面，如果驅動器突然消失（斷開連接或完全死亡，而不是死亡並產生錯誤），則它將是一個有故障的驅動器（ZFS 會將此類驅動器標記為“故障”）。不幸的是，BTRFS 可能沒有意識到在安裝檔案系統時驅動器已消失，正如 09/2015 的郵件清單條目中所指出的那樣（這可能已修補）：

不同之處在於，我們有程式碼來偵測掛載時不存在的設備，但我們還沒有程式碼來偵測它落在已掛載的檔案系統上。我不知道為什麼對設備消失進行正確檢測似乎不是優先事項，但這是與安裝行為不同的問題。

https://www.mail-archive.com/[電子郵件受保護]/msg46598.html

到那時 dmesg 中將會有大量錯誤訊息，因此 grep dmesg 可能不可靠。
對於使用 BTRFS 的伺服器，可能需要進行自訂檢查（cron 作業），如果 RAID 陣列中至少有一個磁碟機消失（即無法再存取），則該檢查會傳送警報...

答案2

從 btrfs-progs v4.11.1 開始，stats 具有 --check 選項，如果任何值不為零，則該選項將傳回非零，因此無需使用正規表示式。

device stats -c /

答案3

我不會依賴 stats 命令來取得錯誤通知，因為如果磁碟機突然消失，此命令不會傳回錯誤。您可以透過斷開SATA電纜或拉動驅動器來測試它 - 不建議用於重要檔案系統。

btrfs device stats /

重新啟動後，btrfs 顯示缺少驅動器，但這可能為時已晚。

btrfs fi show

答案4

聽起來像是系統監控的任務。存在一個實作 Nagios 外掛程式 API 的檢查，稱為：檢查btrfs。正如您在原始程式碼中看到的，它有一個名為 的函數，check_dev_stats該函數檢查設備統計信息，如果任何值非零，則該函數將變得至關重要。它還檢查分配問題。尚不清楚的是如果一個磁碟不存在或離線，檢查的行為如何。

PS：該插件在Debian中打包：監控插件 btrfs

相關內容