The article shows how to spot an XFS filesystem that won’t mount after a power outage or driver hiccup, by looking for I/O error messages in the logs. It then explains step‑by‑step: unmount the device, run `fsck.xfs -n` to preview problems, and finally execute `fsck.xfs -f` to rebuild corrupted structures while warning not to interrupt a long repair on large disks. After the check finishes you can remount the partition, verify that files are accessible, and optionally back it up with tools such as rsync or dd for extra safety. The author concludes by sharing a personal success story where a quick repair restored their data in under a day, encouraging readers to give the procedure a try.

How to Check and Repair an XFS Filesystem on RHEL or CentOS

After a sudden power cut or a faulty driver update, you may find your XFS‑formatted drive refusing to mount with a cryptic “I/O error” message. In this quick guide I’ll walk you through the exact steps to detect corruption and fix it without losing data.

1. Spot the Symptoms

If mount or the boot process stalls on an XFS partition, look for messages like:

XFS: Unable to read superblock at block 0x... : I/O error

That’s your red flag that the filesystem may be corrupted and needs a check.

2. Make Sure It’s Unmounted

fsck.xfs (the tool used to repair XFS) refuses to run on a mounted filesystem. If it is currently in use, you’ll either need to boot into rescue mode or unmount it from another session:

sudo umount /dev/mapper/centos-root   # replace with your actual device

If the mount point is busy, try lsof or fuser to find the culprit and stop it.

3. Do a Dry‑Run First

Before you let XFS bite its own tail, preview what would happen:

sudo fsck.xfs -n /dev/mapper/centos-root

The -n flag tells the tool to read only and report problems without touching anything. Read the output carefully; it will list missing inode blocks, corrupted directories, or bad superblocks.

4. Run a Full Repair

Once you’re comfortable with what needs fixing, drop the dry‑run flag:

sudo fsck.xfs -f /dev/mapper/centos-root

-f forces a check even if the filesystem appears clean. XFS will rebuild internal structures, reallocate bad blocks if possible, and rewrite the superblock.

If you’re dealing with a large disk (tens of gigabytes), this can take a while. Be patient—interrupting it mid‑repair could leave the partition in an even worse state.

5. Verify the Result

After repair completes, mount the filesystem again:

sudo mount /dev/mapper/centos-root /mnt

If it mounts cleanly and you can read/write files, congratulations! If you still see errors, double‑check that the underlying block device isn’t physically damaged. In some cases, a bad SSD or failing SATA controller will keep throwing “I/O error” even after XFS fixes everything.

6. Back It Up (Optional but Recommended)

If you haven’t already, now’s a good time to snapshot or backup the repaired partition. A quick rsync -avx /mnt /backup or dd if=/dev/mapper/centos-root of=backup.img bs=64K conv=noerror,sync can save hours of troubleshooting later.

I’ve seen this exact scenario after a bad driver update that misreported the sector size on my CentOS server. The XFS filesystem refused to mount, and after a quick fsck.xfs -f, everything was back up in one afternoon. Give it a go; your data deserves a second chance.