我有一個 XFS 文件系統，其中的文件系統錯誤影響了一些非關鍵文件。我想修理它；企業希望繼續執行這些錯誤。 不修復出現“結構需要清理”錯誤的 XFS 文件系統的已知風險是什麼？

企業希望避免可能需要的冗長維護視窗。我一直堅信不能容忍文件系統損壞。除了我自己的 FUD 之外，企業會問我修復它的原因。

需要什麼樣的答案

我已經有意見了；我需要的不止這些。

答案應該有證據支持（軼事是可以的，但前提是它們是第一手記錄的。我們不需要“有人告訴我”的答案）。 專家意見是可以的，例如來自 XFS FAQ 的回答，或者來自熟悉 XFS 內部的開發人員的回答）。

請不要外行意見。我正在尋找證據、可靠的軼事和XFS 專家意見。

否定答案（例如“在類似情況下，我跑了一年，沒有遇到嚴重問題）是可以的。

文件系統詳細資訊。

文件系統為 5.4T，使用了 3.9T (72%)。

有 46.6M 文件。

錯誤詳情

有 55 個損壞的目錄會導致應用程序報告“結構需要清理”，ls如此XFS 常見問題條目中所述：find

問：我看到應用程序返回錯誤 990 或“結構需要清理”，這是怎麼回事？

錯誤 990 代表 EFSCORRUPTED，這通常意味著 XFS 檢測到文件系統元數據問題並已關閉文件系統以防止進一步損壞。此外，大約從 2006 年 6 月開始，我們從 EFSCORRUPTED/990 轉換為使用 EUCLEAN，“結構需要清潔”。不幸的是，原因幾乎可以是任何東西——文件系統、虛擬記憶體管理器、捲管理器、設備驅動程序或硬體。最初發生這種情況時應該有詳細的控制台消息。這些消息包含重要資訊，向開發人員提供有關最早檢測到問題的提示。它可以保護您的數據。您可以使用 xfs_repair 來解決問題（解除安裝文件系統）。

記錄到所有的 XFS 錯誤syslog如下所示：

XFS (sdb): Metadata corruption detected at xfs_inode_buf_verify+0x6d/0xe0 [xfs], block 0x50
XFS (sdb): Unmount and run xfs_repair
XFS (sdb): First 64 bytes of corrupted metadata buffer:
ffff88073fa79000: 49 4e 41 ff 02 01 00 00 00 00 01 f6 00 00 01 f7  INA.............
ffff88073fa79010: 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 ed  ................
ffff88073fa79020: 59 1b af d2 09 62 5c 17 4f e8 f8 73 00 00 00 00  Y....b\.O..s....
ffff88073fa79030: 57 e0 73 b2 27 23 63 cd 00 00 00 00 00 00 00 2f  W.s.'#c......../
XFS (sdb): metadata I/O error: block 0x50 ("xfs_trans_read_buf_map") error 117 numblks 16
XFS (sdb): xfs_imap_to_bp: xfs_trans_read_buf() returned error 117.

這些錯誤重複多次，但僅針對兩個塊。

文件系統應該真正離線並檢查/修復，至少有兩個很好的理由：

• 目錄上的元數據錯誤基本上會將它們鎖定在您的控制之外。您不能ls使用它們，也不能在其中創建/刪除文件。
• 元數據錯誤會觸發 XFS 故障安全機制 - 文件系統關閉。如果發生這種情況，您的客戶將出現計劃外的停機時間，也許是有史以來最糟糕的時刻。最好在安靜的時間安排停機時間（即：在夜間）。

一些建議：

• 在執行 full-scale 之前xfs_repair，您可以使用轉儲所有文件系統元數據xfs_metadump並在它們上執行“虛擬” xfs_repair。這將使您有可能觀察xfs_repair將在您的文件系統上做什麼
• 在進行任何修復嘗試之前，請確保擁有有效且最近的備份
• 如果您真的，真的，真的無法關閉文件系統，並且如果有問題的目錄中包含的文件不重要/不重要，您可以嘗試刪除目錄本身。這將有效地“斷開”有問題的元數據區域。一定要明白這只是一個（壞的）解決方法；此外，如果刪除失敗，XFS 可能會關閉整個文件系統，迫使您進行計劃外停機。

引用自：https://serverfault.com/questions/851204