通過編輯 fstab 文件修復文件系統
是否可以通過重新編輯 fstab 文件來執行 xfs 修復?
/dev/mapper/vg-linux_root / xfs defaults 0 0 UUID=7de1dc5c-b605-4a6f-bdf1-f1e869f6ffb9 /boot xfs defaults 0 0 /dev/mapper/vg-linux_var /var xfs defaults 0 0 /dev/mapper/vg-linux_swap swap swap defaults 0 0
我不確定,但將最後一個數字從 0 替換為 1 ,對嗎?
不,僅編輯 /etc/fstab 不會導致執行 xfs_repair。
對於其他文件系統類型,它會起作用。但是 XFS 在這裡很特別。
在 XFS 文件系統上將第 6 個欄位更改為
/etc/fstab
非零值將導致系統執行fsck.xfs
,其手冊頁顯示:NAME fsck.xfs - do nothing, successfully [...] However, the system administrator can force fsck.xfs to run xfs_re‐ pair(8) at boot time by creating a /forcefsck file or booting the sys‐ tem with "fsck.mode=force" on the kernel command line.
所以,通常
fsck.xfs
什麼都不做。如果你真的想
xfs_repair
在啟動時執行,則必須同時滿足兩個條件:a) 對於所討論的 XFS 文件系統,第 6 個欄位
/etc/fstab
必須為非零,以便fsck.xfs
執行。b)
/forcefsck
文件必須存在於根文件系統上(或者可能在 initramfs 中,如果計劃檢查根文件系統),或者核心命令行必須具有fsck.mode=force
引導選項。這將導致fsck.xfs
執行xfs_repair
而不是什麼都不做。那麼 xfs_repair 有什麼特別之處呢?
XFS 文件系統和
xfs_repair
工具都將假定底層磁碟狀況良好,或者至少能夠用內置備用塊透明地替換壞塊(就像所有現代磁碟一樣)。如果現代磁碟具有作業系統可見的持久性壞塊,通常意味著內置的備用塊機制已經被壞塊的數量所淹沒,並且磁碟可能很快就會完全失效。的手冊頁
xfs_repair
說:Disk Errors xfs_repair aborts on most disk I/O errors. Therefore, if you are trying to repair a filesystem that was damaged due to a disk drive failure, steps should be taken to ensure that all blocks in the filesystem are readable and writable before attempting to use xfs_repair to repair the filesystem. A possible method is using dd(8) to copy the data onto a good disk.
因此,您可能不應該
xfs_repair
在正常情況下設置為自動執行。如果 XFS 文件系統有錯誤,您應該始終首先評估底層磁碟的狀況:
smartctl -a /dev/<disk device>
這可能很有用,因為可能dd
用於讀取分區/LV 的全部內容/dev/null
並查看該命令可以在沒有錯誤的情況下完成。如果磁碟出現故障,您應該首先將分區/LV 的內容複製到一個新的、無錯誤的磁碟(可能使用
dd
orddrescue
),然後才應該嘗試xfs_repair
在無錯誤磁碟上的文件系統上執行。
xfs_repair
如果即使您的磁碟狀況良好,您也知道某些東西會導致文件系統級錯誤,那麼在引導時自動執行可能是一個合適的解決方法。但這只是一種解決方法,而不是修復方法:您應該找出導致文件系統錯誤的原因,並修復根本原因。(可能是文件系統驅動程序錯誤,需要更新的核心包來修復?)