Speeding Up e2fsck: Bad Blocks Testing with Lbadblocks.txt and -c

Use the -c flag with e2fsck to perform a read-only bad block check before running the filesystem repair. This process identifies damaged sectors and updates the bad block inode, preventing future data corruption on those specific blocks without requiring external tools or manual file management.

Understanding the -c Flag in e2fsck

The e2fsck utility is the standard tool for checking and repairing ext2, ext3, and ext4 filesystems in Linux environments. By default, it verifies the structural integrity of the filesystem metadata, such as inodes, directories, and block groups. However, it does not inherently scan the physical storage media for hardware defects unless explicitly instructed to do so. The -c option instructs e2fsck to run a bad block check using the badblocks program internally. When you append this flag to your command, the utility pauses the standard filesystem checks to first read every block on the device. It looks for unreadable sectors that indicate physical damage to the disk drive or SSD controller. If the check finds any bad blocks, it automatically adds them to the filesystem's bad block inode. This ensures that the filesystem allocator avoids writing new data to these compromised areas in the future. It is important to note that there is no double -c flag. Using --check-badblocks or multiple instances of -c is incorrect syntax and will likely result in an error from the parser. The single -c flag is the correct and only way to trigger this specific behavior within e2fsck.

Read-Only vs. Read-Write Checks

By default, the -c flag performs a read-only test. This means it attempts to read data from every block to verify if it can be retrieved correctly. A read-only test is faster than a write test because it does not alter the data on the disk. This is generally sufficient for detecting most types of physical degradation. If you suspect more severe issues or want to ensure that the drive can actually write data to those sectors, you can use the -c -c syntax? No, that is invalid. Instead, you should look at the underlying badblocks options if you need a write test. However, e2fsck itself primarily supports the read-only check via the single -c flag. For a comprehensive write test, administrators often run badblocks separately before mounting the filesystem, then pass the resulting list to e2fsck using the -l (lowercase L) flag. But for quick identification during a repair session, the single -c is the standard approach.

Step-by-Step Execution Guide

Before running any filesystem checks, you must ensure the target partition is unmounted. Running e2fsck on a mounted filesystem can lead to catastrophic data loss or inconsistent states. Always boot from a live USB or enter recovery mode if the root filesystem needs checking. Follow these steps to perform a safe bad block check:

1. Identify the Partition: Use lsblk or df -h to determine which device corresponds to your filesystem. Ensure it is not currently mounted by checking the output of mount.
2. Unmount the Filesystem: Execute umount /dev/sdX1 replacing /dev/sdX1 with your actual partition identifier. If the system complains about busy devices, identify the processes holding the mount open using fuser -m /dev/sdX1 and terminate them.
3. Run the Check: Type e2fsck -c /dev/sdX1. The system will begin scanning. You may see messages indicating the progress of the bad block check. This process can take a long time depending on the size of the drive and its health.
4. Review Results: Once complete, e2fsck will report whether any bad blocks were found. If none were found, it proceeds to the standard filesystem consistency check. If bad blocks were found, they are recorded in the bad block inode.

Performance Considerations and Alternatives

Running the bad block check significantly increases the time required for e2fsck to complete. For large hard drives, this operation can take several hours. If you are performing routine maintenance on a healthy system, you might skip this step unless you have specific reasons to believe the hardware is failing. Some users attempt to speed up this process by manually creating a file named Lbadblocks.txt and trying to feed it into e2fsck. This is a misconception. e2fsck does not accept a generic text file named Lbadblocks.txt directly. Instead, it uses the -l flag followed by the path to a file containing the list of bad blocks. For example: e2fsck -l /path/to/bad_blocks.txt /dev/sdX1. The file must contain one block number per line. If you already know the bad blocks from a previous scan, using the -l flag is much faster than re-running the physical scan with -c. This is useful when you have performed a deep scan with badblocks and saved the results, but you need to apply those findings to the filesystem structure immediately. For more information on handling low-level file operations, you might find our guide on How to Shrink Sparse Files in Linux After Copying Without the -S Operator helpful for understanding how Linux handles block allocation efficiently.

Common Pitfalls

A frequent error occurs when users try to run e2fsck -c on a filesystem that is already corrupted beyond repair. In such cases, the bad block check might fail to start, or the subsequent filesystem repair might fail to update the bad block inode due to permission errors or missing superblock structures. Always verify the superblock integrity first. Another pitfall is confusing the -c flag with other flags like -f (force) or -y (assume yes). The -c flag is strictly for bad block detection. It does not fix filesystem inconsistencies; it only prepares the filesystem to avoid bad sectors. You still need to let e2fsck proceed with its normal repair logic after the check completes. For troubleshooting connectivity issues that might arise if you are performing these checks over SSH, refer to our article on Troubleshooting kex_exchange_identification Error in Linux SSH Connection, as network drops during long-running disk checks can interrupt the process.

Frequently Asked Questions

Does the -c flag fix bad blocks?

No, the -c flag does not repair physical damage on the disk. It only detects existing bad blocks and marks them in the filesystem so that the operating system stops allocating data to those sectors. Physical repair requires replacing the faulty hardware component.

Can I use -c on a mounted filesystem?

Absolutely not. Running e2fsck with any flags, including -c, on a mounted filesystem is dangerous and can lead to data corruption. You must unmount the partition before initiating the check to ensure exclusive access to the disk blocks.

What is the difference between -c and -l?

The -c flag triggers a real-time read-only scan of the entire disk to find bad blocks. The -l flag takes a pre-existing list of bad blocks from a file and applies them to the filesystem without performing a new physical scan. Use -l if you already have the bad block list from a prior badblocks run.

How long does the -c check take?

The duration depends entirely on the size of the drive and its rotational speed or interface type. For a 1TB HDD, it can take several hours. For modern NVMe SSDs, it may be faster, but still significant. There is no way to significantly accelerate this process without skipping the check entirely.

What happens if bad blocks are found?

If bad blocks are detected, e2fsck updates the special bad block inode associated with the filesystem. This tells the ext2/ext3/ext4 driver to exclude those specific block numbers from future allocation requests. The rest of the filesystem check continues normally to fix logical inconsistencies.