Why fsck.xfs Succeeds Without Checking Your XFS Filesystem

Run fsck.xfs hoping for a health report and you get status 0 and a pointer elsewhere instead. This guide covers what fsck.xfs actually checks, why a successful exit does not certify an XFS filesystem, and where a real consistency check belongs. On this machine the command comes from xfsprogs 6.6.0-1ubuntu2.1. Allow about ten minutes. The verification steps are read-only and normally need no elevated privileges.

1. Check the installed command

Start by confirming that the XFS checker wrapper is installed and identifying the package version. These commands only inspect the executable and package database:

$ command -v fsck.xfs
/usr/sbin/fsck.xfs
$ dpkg-query -W -f='${Package} ${Version}\n' xfsprogs
xfsprogs 6.6.0-1ubuntu2.1
$ xfs_repair -V
xfs_repair version 6.6.0

2. See the normal no-op result

The fsck.xfs(8) manual describes this command as deliberately successful without performing a consistency check. XFS is a journaling filesystem, and normal journal recovery happens when the filesystem is mounted. Run the command with no arguments to see the installed wrapper's ordinary message:

$ fsck.xfs
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).
$ printf 'exit status: %s\n' "$?"
exit status: 0

Status 0 here means that fsck.xfs completed its intended no-op path. It does not mean that blocks, allocation groups or metadata were examined. This is the first trap: the name looks like a conventional filesystem checker, but the XFS entry in the generic fsck framework exists mainly to keep boot-time tooling uniform.

3. Understand what a filesystem argument changes

The synopsis accepts one or more filesystem arguments, but that does not turn the command into a checker. With a path that exists, the installed wrapper still prints the hand-off message and exits successfully:

$ fsck.xfs /etc/fstab
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).
$ printf 'exit status: %s\n' "$?"
exit status: 0

/etc/fstab is used here only as an existing, harmless path for a local smoke test. It is not an XFS device and must not be offered as a repair target. For a real device, replace the placeholder below with the exact block device from your host:

$ fsck.xfs /dev/your-xfs-device

Do not paste that placeholder literally. On the installed xfsprogs wrapper, a nonexistent argument is rejected with an operational error, rather than being treated as a successful no-op:

$ fsck.xfs /dev/obvious-nonexistent-placeholder
/usr/sbin/fsck.xfs: /dev/obvious-nonexistent-placeholder does not exist
$ printf 'exit status: %s\n' "$?"
exit status: 8

The distinction matters in scripts. A status of 0 from an existing path says that the wrapper declined to check it. A status of 8 in this example says the wrapper could not operate on the supplied path. Neither result is a filesystem health report.

4. Use xfs_repair for an actual consistency check

If you need to inspect or repair damaged XFS metadata, the manual directs you to xfs_repair(8). That is a separate tool with different safety rules: it can change filesystem metadata, so treat it as a privileged maintenance operation and establish the device, mount state, backup position and recovery plan before running it.

For a first investigation, identify the filesystem without changing it:

$ findmnt -t xfs
$ lsblk -f

These commands show mounted XFS filesystems and filesystem metadata as reported by the host. They do not prove consistency and they do not authorise a repair. If the output is unclear, stop before using elevated privileges. A mistaken device name is an irreversible class of error when a repair tool is involved.

5. Know what boot forcing means

The fsck.xfs manual documents two ways for an administrator to force the wrapper to run xfs_repair during boot: create /forcefsck, or boot with fsck.mode=force on the kernel command line. These are deliberate boot configuration changes, not routine options for checking whether a disk is healthy.

Do not create /forcefsck or edit a boot entry as part of a casual test. If you inherit either setting, remove the file or the kernel parameter after the planned maintenance window, following your distribution's boot process. Keep a record of who requested the forced check and what recovery procedure will be used if it reports a dirty log or damaged metadata.

Also separate journal recovery from repair. XFS normally recovers its journal during mount, so a successful mount tells you that the kernel completed the mount operation, not that every piece of filesystem metadata is perfect. Conversely, a mount failure is a reason to investigate carefully, not permission to guess at a device or force a repair.

Common traps

• Status 0 is not a clean bill of health. The command is designed to do nothing successfully.
• A generic fsck invocation proves nothing either. It dispatches to filesystem-specific helpers, and this helper still has the XFS no-op contract.
• Do not run xfs_repair against a guessed path. Never target a mounted filesystem or a production device during normal service operation; read its manual and your platform's maintenance instructions first.
• Do not confuse the three failure types. A missing device, a wrapper error and a filesystem error are different things: capture the exit status immediately and retain the command's diagnostic text.

The useful checkpoint is simple: if your command output only says to see xfs_repair(8), you have verified the wrapper, not the filesystem. If you need a health decision, move to the XFS-specific maintenance workflow with the correct device and an approved recovery plan.