是否可以通过重新编辑 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 ,对吗?
答案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
或),然后才应尝试在无错误磁盘上的文件系统上ddrescue
运行。xfs_repair
xfs_repair
如果您知道某些原因导致文件系统级错误,即使您的磁盘状况良好,在启动时自动运行可能是一个合适的解决方法。但这只是一种解决方法,而不是修复:您应该找出导致文件系统错误的原因,并修复根本原因。 (也许是文件系统驱动程序错误,需要更新的内核包来修复?)
答案2
如果上面的文件/dev/sda
有错误,那么你需要运行fsck
它。请记住,它实际上不会修复磁盘本身,而只会修复文件。如果磁盘确实有错误并且出现故障,那么最好更换磁盘并从备份中恢复数据,因为如果它变得足够糟糕,您可能会丢失数据,尤其是当磁盘完全损坏时。