1. How to check XFS filesystem version?
Since version 3.15, the kernel tells you the version of XFS used in each filesystem as it mounts it; dmesg | grep XFS should give you something like
[1578018.463269] XFS (loop0): Mounting V5 Filesystem
Instead of loop0 on your system you'll get the underlying device, and V5 will be replaced by whatever version your filesystem uses.
2. Checking and Repairing an XFS File System
Note
If you have an Oracle Linux Premier Support account and encounter a problem mounting an XFS file system, send a copy of the /var/log/messages file to Oracle Support and wait for advice.
If you cannot mount an XFS file system, you can use the xfs_check command to check its consistency. Usually, you would only run this command on the device file of an unmounted file system that you believe has a problem. If xfs_check displays any output when you do not run it in verbose mode, the file system has an inconsistency.
# xfscheck device
If you can mount the file system and you do not have a suitable backup, you can use xfsdump to attempt to back up the existing file system data, However, the command might fail if the file system's metadata has become too corrupted.
You can use the xfs_repair command to attempt to repair an XFS file system specified by its device file. The command replays the journal log to fix any inconsistencies that might have resulted from the file system not being cleanly unmounted. Unless the file system has an inconsistency, it is usually not necessary to use the command, as the journal is replayed every time that you mount an XFS file system.
# xfs_repair device
If the journal log has become corrupted, you can reset the log by specifying the -L option to xfs_repair.
Warning
Resetting the log can leave the file system in an inconsistent state, resulting in data loss and data corruption. Unless you are experienced in debugging and repairing XFS file systems using xfs_db, it is recommended that you instead recreate the file system and restore its contents from a backup.
If you cannot mount the file system or you do not have a suitable backup, running xfs_repair is the only viable option unless you are experienced in using xfs_db.
xfs_db provides an internal command set that allows you to debug and repair an XFS file system manually. The commands allow you to perform scans on the file system, and to navigate and display its data structures. If you specify the -x option to enable expert mode, you can modify the data structures.
# xfs_db [-x] device
For more information, see the xfs_check(8), xfs_db(8) and xfs_repair(8) manual pages, and the help command within xfs_db.
3. xfs_repair
If you're attempting to run xfs_repair, getting the error message that suggests mounting the filesystem to replay the log, and after mounting still receiving the same error message, you may need to perform a forced repair (using the -L flag with xfs_repair). This option should be a last resort.
For example, I'll use a case where I had a corrupt root partition on my CentOS 7 install. When attempting to mount the partition, I continually received the below error message:
mount: mount /dev/mapper/centos-root on /mnt/centos-root failed: Structure needs cleaning
Unfortunately, forcing a repair would involve zeroing out (destroying) the log before attempting a repair. When using this method, there is a potential of ending up with more corrupt data than initially anticipated; however, we can use the appropriate xfs tools to see what kind of damage may be caused before making any permanent changes.
Using xfs_metadump and xfs_mdrestore, you can create a metadata image of the affected partition and perform the forced repair on the image rather than the partition itself. The benefits of this is the ability to see the damage that comes with a forced repair before performing it on the partition.
To do this, you'll need a decent sized USB or external hard drive. Start by mounting the USB drive - my USB was located at /dev/sdb1, yours may be named differently.
mkdir -p /mnt/usb
mount /dev/sdb1 /mnt/usb
Once mounted, run xfs_metadump to create a copy of the partition metadata to the USB - again, your affected partition may be different. In this case, I had a corrupt root partition located at /dev/mapper/centos-root:
xfs_metadump /dev/mapper/centos-root /mnt/usb/centos-root.metadump
Next, you'll want to restore the metadata in to an image so that we can perform a repair and measure the damage.
xfs_mdrestore /mnt/usb/centos-root.metadump /mnt/usb/centos-root.img
I found that in rescue mode xfs_mdrestore is not available, and instead you'll need to be in rescue mode of a live CentOS CD.
Finally, we can perform the repair on the image:
xfs_repair -L /mnt/usb/centos-root.img
After the repair has completed and you've assessed the output and potential damage, you can determine as to whether you'd like to perform the repair against the partition.
To run the repair against the partition, simply run:
xfs_repair -L /dev/mapper/centos-root
Don't forget to check the other partitions for corruption as well. After the repairs, reboot the system and you should be able to successfully boot.
Remember that the -L flag should be used as a last resort where there are no other possible options to repair.