is it possible to run xfs repair by re-edit the fstab file?

/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

I am not sure but by replace the last number from 0 to 1 , is it right?

  • What are you trying to repair? Is an error with one of the drives or logical volumes or do you mean for something that might happen in the future? More information is needed on what you are trying to do. – Nasir Riley Mar 21 at 19:12
  • we saw errors from dmesg about the sda ( is the OS ) , so we want to understand if edit fstab from 0 to 1 , will help to repair the OS – yael Mar 21 at 19:16

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.

So, ordinarily 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 says:

   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.

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 dd or ddrescue), and only then you should attempt to run xfs_repair on the filesystem on the error-free disk.

Running 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?)

| improve this answer | |

If the files on /dev/sda have errors, then you need to run fsck on it. Keep in mind that it won't actually repair the disk itself but just the files. If the disk indeed has errors and it's failing, then it's best to replace the disk and restore the data from a backup because if it gets bad enough, you'll possibly have data loss especially if the disk dies altogether.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.