Running fsck on a Mounted Partition

1. Overview

In this tutorial, we’ll explore whether we can run fsck on a mounted partition. We’ll discuss potential issues why running fsck on a mounted partition is problematic. Then, we’ll also understand insights into running fsck on a read-only mounted file system. Additionally, we’ll also look at the limitations and caveats involved.

Finally, we’ll see a few alternative ways for file system maintenance, such as adopting file systems like XFS, FFS, and UFS.

2. What Is fsck?

fsck is a utility that we can use to verify and repair inconsistencies in a file system. It scans the file system’s metadata structures, such as inodes and superblocks, to ensure they’re consistent with the data stored on the disk.

The primary goal of fsck is to maintain the integrity of the file system and prevent data loss or corruption.

3. Running fsck on a Mounted Partition

When a file system is mounted, the operating system assumes that it’s in a consistent state and allows read and write operations on it. However, fsck directly accesses the storage device and modifies file system structures. Therefore, running fsck on a mounted partition introduces conflicts against the operating system.

As an example, let’s first check whether the partition is mounted:

$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
tmpfs             399300     1488    397812   1% /run
/dev/vda2       32844560 12696648  18453960  41% /
...

As we can see, the partition we’re checking is mounted on /. Now, let’s run fsck on it:

$ sudo fsck /dev/vda2
fsck from util-linux 2.38.1
e2fsck 1.47.0 (5-Feb-2023)
/dev/vda2 is mounted.
e2fsck: Cannot continue, aborting.

Notably, we get an error. However, if we run fsck with the -n flag, it runs in read-only mode:

$ sudo fsck -n /dev/vda2
fsck from util-linux 2.38.1
e2fsck 1.47.0 (5-Feb-2023)
Warning!  /dev/vda2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/vda2: clean, 208641/2097152 files, 3350302/8387840 blocks

As we can see, it ran successfully, but we should know that the result printed by fsck in -n mode is incorrect. In contrast, the combination of the read-only mounted partition and the -n flag should yield an accurate report.

In the following sections, we’ll discuss the risks of running fsck on a mounted partition and running fsck on a read-only partition.

3.1. Risks

It’s essential to understand that fsck is a separate program from the file system kernel code. While fsck analyzes the file system’s metadata and performs repairs, the kernel code manages the file system’s operations during normal operation.

These two entities operate independently, and running fsck on a mounted partition means there’s no coordination between them. When fsck runs on an active file system, it expects exclusive control over the file system structures it examines.

However, if the kernel code modifies the file system while fsck is running, inconsistencies and conflicts can arise. This is one of the fundamental reasons to avoid running fsck on a mounted partition is the potential for data corruption. Therefore, to ensure accurate results and prevent data corruption, fsck requires exclusive access to the file system.

3.2. Running fsck on a Read-Only Partition

It’s safe to perform a file system check on a read-only partition as the file system is in a static state. Thus, it minimizes the risk of inconsistencies.

As an example, we’ll mount the partition as read-only:

$ sudo mount -o remount,ro /dev/vda2

Now, we can run fsck with the -n flag on /dev/vda2:

$ sudo fsck -n /dev/vda2
fsck from util-linux 2.38.1
e2fsck 1.47.0 (5-Feb-2023)
/dev/vda2: clean, 2096723/2097152 files, 8387752/8387840 blocks

With this approach, any repairs or modifications suggested by fsck cannot be applied to the file system while it’s still mounted. Therefore, we should unmount the partition and run fsck in an appropriate mode to perform the necessary repairs.

Moreover, there’s a limitation to this approach. Running fsck on a read-only mounted file system doesn’t address underlying hardware issues or other factors that can affect data integrity. Therefore, it’s crucial to have proper backups in place to mitigate the risk of data loss.

4. Possible Alternatives

Obviously, a good approach is to schedule maintenance for the file system to be unmounted so we can execute fsck safely. However, there are certain file systems that offer online file system checking.

For instance, XFS offers the capability to perform consistency checks on a mounted file system while it’s in a read-write state through the xfs_check utility. Unfortunately, there’s a higher likelihood of encountering false errors during the check.

Apart from that, newer versions of FFS (Fast File System) and UFS (Unix File System) have implemented an online checking mechanism that allows fsck to run against a recent snapshot of the file system. This snapshot is a read-only, point-in-time copy-on-write replica of the file system.

When running fsck on a mounted UFS file system, it first creates a snapshot that represents the state of the file system at the specific moment. This snapshot is used for the consistency check while the actual file system remains active and writable.

fsck analyzes the snapshot’s metadata to identify any inconsistencies or errors. If there are issues, fsck tries to correct them through system calls rather than directly modifying the raw disk.

5. Conclusion

In this article, we explored the possibility of running fsck on a mounted partition. We discussed the potential risks and issues associated with it. We also examined the option of running fsck on a read-only mounted file system.

Finally, we learned alternative approaches for file system maintenance, such as using file systems like XFS, FFS, and UFS, which offer online checking mechanisms.