我們有基於 BBB 的定制板，它有 256MB 內存和 4GB 或 eMMC。我們使用 Linux-3.12，在 eMMC 上我們有 ext4 分割區。
我正在編寫一個定期運行並檢查檔案系統錯誤的腳本，如果未安裝分割區，我將嘗試使用 e2fsck 糾正錯誤。
最初我用來e2fsck -n /dev/mmcblk0pN (N is partition number)檢查檔案系統分割區中的錯誤。
但是，當安裝分割區並在分割區上建立檔案時，上述命令開始給出錯誤的結果。
現在我需要一種替代方法來檢查檔案系統錯誤，
其中一個選項是tune2fs -l在該分割區上使用命令檢查Filesystem state欄位。
現在我不確定這個欄位對於檢查檔案系統錯誤是否可靠？這個欄位可以有哪些可能的值？我已經看到了它的值clean，clean with errors但not clean我沒有從手冊頁中獲得更多資訊。
那麼，tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error”檢測檔案系統錯誤可靠嗎？還有其他更好的選擇來檢查分割區中的檔案系統錯誤嗎？
有什麼建議/指示/訊息嗎？
答案1
“Tune2fs -l”將告訴您核心在運行時是否注意到檔案系統損壞問題。例如，如果您要求 ext4 刪除一個文件，而 ext4 發現該文件中的某些區塊已被標記為已釋放，則表示分配位圖已損壞。請注意，當 ext4 發現分配位圖時，它已經損壞。事實上，它可能已經損壞了幾天或幾週，如果您一直在寫入新文件，ext4 可能會為新文件分配用於舊文件的區塊，並且用戶可能會丟失資料結果。
可靠地確定檔案系統是否一致或是否可能存在一定程度的損壞的唯一方法是在其上執行 e2fsck。執行此操作需要卸載檔案系統或建立唯讀快照。 （如果你使用的是LVM，你可以建立一個唯讀快照，檢查唯讀快照，然後如果發現檔案系統損壞，你可以重新啟動系統並讓e2fsck修復檔案系統，或發送電子郵件給系統管理員安排停機時間來修復檔案系統。
綜上所述，如果檔案系統已損壞，最常見的情況很可能是由於硬體問題。這可能是由於核心錯誤造成的，儘管我定期對穩定核心（而不僅僅是上游）運行回歸測試，而且我們已經很長一段時間沒有遇到檔案系統損壞問題了。裝置驅動程式中可能存在記憶體損壞錯誤，且 (a) 裝置驅動程式不是上游，且硬體供應商沒有進行適當的品質控制，或 (b) 此錯誤已在上游修復，甚至推送到最新的穩定內核，但設備內核並沒有從穩定內核系列中取得更新。
請注意，如果您想查看檔案系統是否因核心因明顯錯誤而被絆倒而損壞，則不必只抓取 dmesg 或 /var/log/messages。您也可以嘗試讀取檔案/sys/fs/ext4//first_error_time。如果該檔案包含非零值，它將告訴您核心偵測到檔案系統損壞的時間（使用 Unix 紀元）。該目錄中的errors_count 檔案將告訴您已偵測到多少個檔案系統損壞（但這可能只是系統一次又一次地遇到相同問題）。另外有趣的是，如果您想測試系統如何處理核心偵測到的檔案系統錯誤，您可以嘗試將字串寫入trigger_fs_error 檔案 --- 例如， echo "test error" > /sys/fs/ ext4/sda1/ trigger_fs_error”
最後，請看一下您可以在tune2fs中設定的錯誤行為旋鈕。如果您確實想確保在檢測到檔案系統損壞問題後不會造成更多損壞，則可能需要將檔案系統配置為在發現問題時以唯讀方式重新掛載自身 ---或者可能只是強制重新啟動，以便可以在啟動序列期間運行e2fsck，以在（甚至更多）用戶資料損壞或遺失之前修復問題。