CodeGym /Courses /Docker SELF /Checking and Repairing the File System: fsck Commands

Checking and Repairing the File System: fsck Commands

Docker SELF
Level 6 , Lesson 2
Available

Checking and Repairing the File System: fsck Commands

1. Why is it important to check the file system?

The file system in Linux is actually one of the busiest "employees" of the OS. It works hard while you save files, open programs, or just read data. Now imagine this: at the most critical moment, this employee gets tired and decides to faint (read: the system shut down due to a power outage). This can lead to file table corruption, data loss, or a bunch of other nasty issues.

But what can go wrong?

  1. Sudden power outage — your device suddenly shuts down without finishing writing data.
  2. Storage error — a hard drive or SSD may have hardware failures that damage the file system.
  3. Software bugs — driver or system utility glitches are not out of the question.

Often after such events, the file system becomes unusable, and the system itself might ask you to check its state. That's where fsck, which stands for File System Check, comes to the rescue.


2. What is fsck and How Does It Work?

The Idea Behind the Tool

fsck is a universal utility that checks the integrity of the file system and fixes any errors it finds. It works like a doctor: runs tests, identifies a problem, and if possible, "treats" it. If the problem is too severe, fsck can at least diagnose what exactly went wrong.

When Is fsck Used?

  1. During obvious file malfunctions (for example, files suddenly "disappeared").
  2. If the system doesn’t boot and reports a file system error.
  3. For regular maintenance to make sure everything is okay.

3. Basic syntax of fsck

To use fsck, the following command is typically used:

fsck [options] <device>

Main options:

  • -y — Automatically confirm fixes. This is handy if you don't want to sit there and keep pressing yes for every prompt.
  • -n — Check only, no fixing (dry run). Useful for analyzing the situation if you're worried about breaking something.
  • -t — Specify the type of file system (e.g., ext4, xfs).
  • -r — Enable interactive mode (you'll confirm each fix).

4. Practice: File System Check

Let's start with a simple check. Suppose we have a device /dev/sdb1 that we want to inspect.

Step 1: Check Without Fixing

First, let's assess the state of the file system without making any changes:

fsck -n /dev/sdb1

After running the command, you'll see a list of detected issues, if there are any. Here's an example of the output:

Inodes that were part of a corrupted orphan linked list found.
Filesystem errors detected. Run fsck to repair.

Step 2: Automatic Fix

Now let's enable error correction mode:

fsck -y /dev/sdb1

fsck will attempt to fix each detected error and automatically confirm actions. This might take some time if the device is large.


5. What to do if the file system is in use?

Error when starting fsck

If you try to start fsck on a partition that is already mounted, you'll get a warning:

fsck: cannot check a mounted filesystem.

This happens because checking a mounted file system can lead to data corruption. There are a few ways to solve this problem:

  1. Mount the device in read-only mode.
mount -o remount,ro /dev/sdb1
  1. Use LiveCD or LiveUSB.

Boot from a live disk or USB stick to perform the check on an already unmounted device.

  1. Use recovery mode.

Restart the system in recovery mode, which usually provides a safe environment for performing the check.

Features of checking the root file system /

The root file system is a unique case because it's actively used by the system. To run fsck for such a partition, you need to:

  1. Switch to single-user mode using the command:
systemctl isolate rescue.target
  1. Manually start fsck:
fsck -y /

6. Common Errors and Their Fixes

Corrupted inodes

If fsck reports corrupted inodes (structures that store file information), it will suggest deleting them. This is safe, as the corrupted inode is no longer linked to current files.

Lost files

Sometimes, after running fsck, lost files end up in the lost+found directory at the root of the file system. You can manually check this location to recover important data.

Important Tips

  1. Always make backups before running checks. Although fsck is usually safe, fixes may result in data loss.

  2. Do not run fsck on mounted partitions. This may lead to data corruption.

  3. Use the -n flag for a preliminary check. If you're unsure whether to fix errors automatically, start with a dry run.


7. Example: Simulating an Error and Fixing It

  1. Create a virtual disk and initialize a filesystem on it:
dd if=/dev/zero of=./disk.img bs=1M count=100
mkfs.ext4 ./disk.img
  1. Mount the disk:
sudo mount ./disk.img /mnt/test/
  1. Simulate damage:
sudo dd if=/dev/zero of=/mnt/test/randomfile bs=512 count=10
  1. Unmount the disk and check its consistency:
sudo umount /mnt/test/
fsck ./disk.img

Follow the outputs of the command to fix the errors.

By this stage, you feel confident in understanding filesystem checks, properly fixing any errors, and preventing failures. Ahead, we'll explore new tools to work with filesystems, but fsck is now your trusty companion for diagnostics and repairs.

1
Task
Docker SELF, level 6, lesson 2
Locked
Basic filesystem check
Basic filesystem check
1
Task
Docker SELF, level 6, lesson 2
Locked
Automatic Error Correction
Automatic Error Correction
1
Task
Docker SELF, level 6, lesson 2
Locked
Checking the root file system
Checking the root file system
1
Task
Docker SELF, level 6, lesson 2
Locked
Creating, corrupting, and repairing a file system
Creating, corrupting, and repairing a file system
Comments
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION