No, just editing /etc/fstab cannot cause xfs_repair to be executed.
For other filesystem types, it would work. But XFS is special here.
Changing the 6th field of
/etc/fstab to a non-zero value on a XFS filesystem will cause the system to run
fsck.xfs, whose man page says:
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 will do nothing at all.
If you really want
xfs_repair to run at boot, there are two conditions that both must be satisfied:
a) The 6th field of
/etc/fstab must be non-zero for the XFS filesystem in question, so that
fsck.xfs will be executed.
b) Either a
/forcefsck file must exist on the root filesystem (or perhaps within initramfs, if planning to check the root filesystem), or the kernel command line must have the
fsck.mode=force boot option. This will cause
fsck.xfs to run
xfs_repair instead of doing nothing.
What's so special with xfs_repair, then?
The XFS filesystem and the
xfs_repair tool both will assume that the underlying disk is in good condition, or at least is capable of transparently replacing bad blocks with built-in spare blocks (as all modern disks do). If a modern disk has persistent bad blocks visible to the operating system, it usually means that the built-in spare block mechanism has already been overwhelmed by the amount of bad blocks, and the disk is probably going to fail completely soon enough anyway.
The man page of
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
So, you probably should not set
xfs_repair to run automatically in normal circumstances.
If a XFS filesystem has errors, you should always first evaluate the condition of the underlying disk:
smartctl -a /dev/<disk device> might be useful, as might be using
dd to read the whole contents of the partition/LV to
/dev/null and seeing that the command can complete without errors.
If the disk is failing, you should first copy the contents of the partition/LV to a new, error-free disk (perhaps using
ddrescue), and only then you should attempt to run
xfs_repair on the filesystem on the error-free disk.
xfs_repair automatically at boot time might be an appropriate workaround if you know that something is causing filesystem-level errors even when your disks are in good condition. But that is just a workaround, not a fix: you should find out what is causing the filesystem errors, and fix the root cause. (Maybe a filesystem driver bug, requiring an updated kernel package to fix?)