# Why doesn't /sbin/fsck.xfs do 'xfs_repair'?

## lyallp

I recently had problems with corruption of my XFS /usr filesystem.

I tried creating /forcefsck to repair my filesystems, only to have nothing happen.  

I tried booting in single user mode, but good old Bash decides that it wants to access the language files in /usr/lib, so I could not unmount /usr to repair it.

At the time, I had an old (1 year) gentoo boot cd, which did not find or repair the problem (I guess, old version of xfs).

The /sbin/fsck.xfs script codes explicitly for xfs but does not bother to actually execute xfs_repair or xfs_check.

The code is quite simple, for example, I tweaked my own copy as follows :

```
#!/bin/sh -f

#

# Copyright (c) 2006 Silicon Graphics, Inc.  All Rights Reserved.

#

AUTO=false

while getopts ":aA" c

do

        case $c in

        a|A)    AUTO=true;;

        esac

done

eval DEV=\${$#}

if [ ! -e $DEV ]; then

        echo "$0: $DEV does not exist"

        exit 8

fi

if $AUTO; then

        echo "$0: XFS file system."

        xfs_repair $DEV

        retval=$?

else

        #echo "If you wish to check the consistency of an XFS filesystem or"

        #echo "repair a damaged filesystem, see xfs_check(8) and xfs_repair(8)."

        xfs_check $DEV || xfs_repair $DEV

        retval=$?

fi

exit $retval

```

I figure there must be a reason for the script doing nothing.

It wasn't that hard. The only thing I can think of is that the output of xfs_repair would spoil the boot sequence.

----------

## guruvan

The short answer from my own experience is that xfs_check doesn't really _do_ anything, and xfs_repair really needs to be run interactively. 

```

xfs_repair(8)

BUGS

The  filesystem  to  be  checked  and  repaired  must  have  been unmounted cleanly using normal system administration procedures (the umount(8) command or system shutdown), not as a result of a crash or system reset.  If the filesystem has not been unmounted  cleanly, mount it and unmount it cleanly before running xfs_repair.
```

That seems above & beyond the duty of a boot script. 

I've used xfs since the '80s on sgi boxes, and since I could on linux. It's been _extremely_ rare that I've had to run xfs_repair on anything ( compared to fsck/reiserfsck) and most of the time, the drive has physical errors. 

Also, regardless of physical errors on the drive, because the XFS failures are so infrequent, I almost always follow the recommended procedure of using dd to copy the contents of the drive/partition/file to known good storage space, and work on the filesystem there. 

Recovery using this procedure is nearly 100% (a FAR cry from my experiences with reiser3x, where recovery of the files is about 65% and tree is around 5%) Frankly I don't want ANY filesystem's fsck to try to fix my filesystems automatically upon (unattended! spontaneous) boots.

----------

## lyallp

The only reason my XFS was corrupt is because my SATA drive cable was flakey. Result was the bus would occasionally freeze and require a reset, which, caused problems with XFS (which, in my mind, is a rock solid FS).

I have since replaced the SATA cable, and all is well, at this stage.

Additionally, I figured out why xfs_repair is not done in the boot script, the xfs_repair program lives in /usr/bin - it's not available at boot time!

I ended up booting the gentoo livecd (which doesn't boot on my pc without manual assistance - it finds the wrong partition to mount when mounting root from the squashfs) and repairing it that way.

----------

