In this process, we will learn how to check the consistency and optionally repair CentOS 7 filesystems. Filesystem inconsistencies are rare events and filesystem checks normally are running automatically at boot time. But system administrators should also know how to run such tests manually if they believe there is a problem with the filesystem.
To Start With: What Do You Need?
To complete this process, you will require a working installation of the CentOS 7 operating system with root privileges. We will use virtual block devices instead of real disk devices because we cannot apply any file system check on a mounted disk. Therefore, you should have applied the Formatting and mounting a filesystem process and created a 1 gigabyte virtual block device with two partitions of half the total size: first, a partition with an XFS, and then another one with an ext4 filesystem. We will use the virtual block device named /dev/loop0 in this example.
As said before, these can be easily exchanged with real disk names.
The Process
- To begin with, log in as root and show information about the current block devices attached to the system:
lsblk -io NAME,TYPE,SIZE,MOUNTPOINT,FSTYPE,MODEL - Here, you should see two partitions on the loop0 device: /dev/loop0p1 and /dev/loop0p2. If you see that they are currently mounted to the system, unmount them now:
umount /dev/loop0p1 umount /dev/loop0p2 - Now, let’s check the XFS filesystem which in our example is loop0p1 (change appropriately):
xfs_repair -n /dev/loop0p1 - For the second partition on the disk that is ext4, we will use the following line
fsck -f /dev/loop0p2
How Does It Work?
In this process, we have learned how easy it is to run a filesystem check on a XFS or ext4 filesystem. The most important lesson you should have learned here is that you always have to unmount your disk partitions before running any filesystem checks!
So, what did we learn from this experience?
Since we cannot run any filesystem checks on any mounted device, if you want to check your system’s disks and partitions, often you have to run such checks in the rescue mode where your filesystems are not mounted (for example, you cannot unmount the root partition to check because it’s needed by the system all the time, whereas, for a separate home partition, it would be possible).
For the XFS file system, we use the xfs_repair tool, and for all others we will use the fsck program with the -f parameter (force) to check our filesystem.
It is important to note that we always need to run fsck instead of the specific fsck.<file system type> (such as fsck.ext4, fsck.btrfs), because it auto-detects the right tool for you. This is necessary because if you run the wrong specific fsck.<file system type> tool on the wrong filesystem (let’s say running fsck.ext4 on a btrfs filesystem), it can completely destroy it!
There's more…
So far, we have only showed you how to check a filesystem using xfs_repair and fsck. If some errors occur during the “checking” run on an XFS filesystem, run xfs_repair without the -n option—for example, use xfs_repair /dev/loop0p1. On a non-XFS partition, such as ext4, you would run fsck with the -a option (a for auto repair)—for example, fsck -a /dev/loop0p2. For fsck, if you got a lot of errors, it’s best to use -y as well so that you do not have to confirm every error fix.
Now, let’s simulate what would happen if we got a corrupted XFS filesystem using our virtual block device (never do this on any real disk partition!):
- First, mount the /dev/loop0p1 partition to your root filesystem:
mkdir /media/vbd-1 mount -t xfs /dev/loop0p1 /media/vbd-1 - Next, create a large number of files on this mounted filesystem—for example, 2000 files:
for i in {1..2000}; do dd if=/dev/urandom bs=16 count=1 of=/media/vbd1/file$i; done - Now, unmount the device and corrupt the filesystem using dd:
umount /dev/loop0p1
dd bs=512 count=10 seek=100 if=/dev/urandom of=/dev/loop0p1 - Now, run a filesystem check:
xfs_repair -n /dev/loop0p1 - This will most likely show you a list of corrupted files; in order to fix it, use the following line:
xfs_repair /dev/loop0p1
You can also simulate such a filesystem corruption on your ext4 virtual block device, and then repair it using fsck -ay /dev/loop0p2.
