LFCS 91 🐧 Filesystem Integrity — fsck - KandZ

⏱️ Estimated read: 10 min | |

Filesystem corruption is not a theoretical concern. A sudden power loss, a failing disk, or an unclean shutdown can leave metadata in an inconsistent state—inodes marked as allocated with no directory entry, blocks claimed by multiple files, or a superblock that no longer matches reality. The fsck family of tools exists to detect and repair these inconsistencies. On the LFCS exam, filesystem integrity appears in the Storage domain, and the commands differ significantly between ext4 and XFS. Knowing which tool to invoke, how to run it safely, and what to do when the root filesystem is the one that is damaged is the difference between a recoverable system and a dead one.

Key point: Never run fsck on a mounted filesystem unless you know exactly what you are doing. The tool assumes exclusive access to the device. Running it while the filesystem is mounted can cause the very corruption you are trying to fix.

Why fsck exists

The metadata consistency problem. A filesystem is a complex data structure: inodes, directory entries, block bitmaps, and free lists all reference each other. A write to one structure that is not accompanied by a corresponding update to another leaves the filesystem inconsistent. fsck walks these structures and verifies that they agree with each other .

The unclean shutdown problem. Modern filesystems use journaling to avoid full fsck runs after every crash. ext4 replays its journal on mount, which restores consistency for recent transactions. But journaling does not protect against hardware failures, media errors, or bugs. When the journal itself is corrupt, or when the damage predates the journal, fsck is the only tool that can repair the filesystem .

The XFS divergence. XFS does not use fsck in the traditional sense. The fsck.xfs command exists, but it almost always exits with a success status and does nothing. The actual repair tool is xfs_repair, which operates differently from e2fsck: it requires the filesystem to be unmounted (or mounted read-only), and it has its own phases and flags .

The root filesystem problem. The root filesystem cannot be unmounted while the system is running. Running fsck on it from a live system is dangerous. The correct approach is to force a check at the next boot using kernel parameters or tune2fs, or to boot from rescue media and run fsck from there .

The trade-off. fsck is powerful but destructive. It may delete corrupted files, move orphaned inodes to lost+found, and in severe cases, discard entire directory trees. Backing up before running a repair is not optional—it is the first step .

a. Running fsck on ext4 filesystems

The fsck command is a frontend that dispatches to the filesystem-specific checker. For ext4, that checker is e2fsck. The frontend reads the filesystem type and invokes the correct binary, but calling e2fsck directly gives more control over the repair process .

# Unmount the filesystem first
sudo umount /mnt/data

# Check the filesystem state
sudo dumpe2fs -h /dev/sdb1 | grep "Filesystem state"
# Output: Filesystem state: clean with errors

# Run a read-only check (no modifications)
sudo fsck -n /dev/sdb1

# Run an interactive repair
sudo fsck /dev/sdb1

# Run an automatic repair (answer yes to all prompts)
sudo fsck -y /dev/sdb1

The -n flag is critical for diagnosis. It performs a read-only scan and reports every inconsistency without modifying the filesystem. This allows you to assess the damage before committing to a repair that may discard data . The -y flag answers “yes” to every prompt, which is useful for automation but dangerous for manual recovery—you cannot review each decision.

The dumpe2fs output is the diagnostic starting point. A state of clean with errors means the superblock knows about a problem but the filesystem is not marked as requiring a full check on mount. This is a warning that should not be ignored; the filesystem may mount successfully but corrupt data on write .

b. Repairing XFS filesystems with xfs_repair

XFS handles corruption differently. The journal is replayed automatically on mount, and most inconsistencies are resolved without user intervention. When the journal replay is insufficient, xfs_repair is the tool. It must be run on an unmounted filesystem, and it operates in phases: finding the superblock, scanning inodes, checking block allocation, and rebuilding free lists .

# Unmount the filesystem
sudo umount /mnt/data

# Dry run: check without modifying
sudo xfs_repair -n /dev/sdb1

# Repair the filesystem
sudo xfs_repair /dev/sdb1

# If the log is corrupt, clear it (DATA LOSS possible)
sudo xfs_repair -L /dev/sdb1

The -n flag is the XFS equivalent of fsck -n: it scans and reports without writing. The -L flag is the nuclear option. It clears the log, which means any transactions that were in the journal at the time of the crash are lost. This should be used only when xfs_repair reports that the log is corrupt and cannot be replayed .

XFS also provides xfs_scrub, which performs online checking and repair of mounted filesystems. This is a newer tool and not universally available, but it is the preferred method for XFS integrity checks on running systems when it is supported .

c. Handling the root filesystem

The root filesystem is special. It cannot be unmounted, and running fsck on it from a running system is dangerous. The standard approach is to force a check at the next boot. On systemd-based systems, the fsck.mode=force kernel parameter triggers a full filesystem check during the boot sequence .

# For ext4: force a check on next mount
sudo tune2fs -C 1 /dev/sda1

# Or mark the filesystem for a check
sudo tune2fs -E force_fsck /dev/sda1

# For systemd: add fsck.mode=force to the kernel command line
# Edit /etc/default/grub and add to GRUB_CMDLINE_LINUX
# Then update grub and reboot
sudo update-grub

The tune2fs -C 1 command sets the mount count to 1, which is below the maximum mount count threshold, forcing e2fsck to run on the next boot. This is a safe way to schedule a check without editing boot parameters . For XFS, the root filesystem check follows the same pattern: boot from rescue media, run xfs_repair on the root device, and reboot.

If the root filesystem is so corrupt that the system cannot boot, rescue mode is the only option. Booting from a live USB and running fsck or xfs_repair on the root partition is the standard recovery path. The filesystem must not be mounted at the time of the repair .

Complete Example Session

# ============================================
# PART 1: IDENTIFY THE FILESYSTEM TYPE
# ============================================

# The repair tool depends on the filesystem type.
sudo blkid /dev/sdb1
# Output: /dev/sdb1: UUID="..." TYPE="ext4"

# ============================================
# PART 2: UNMOUNT THE FILESYSTEM
# ============================================

# The filesystem must not be mounted during repair.
sudo umount /mnt/data

# Verify it is unmounted
df -Th | grep sdb1
# (no output means unmounted)

# ============================================
# PART 3: CHECK THE FILESYSTEM STATE (EXT4)
# ============================================

# dumpe2fs shows the superblock state.
sudo dumpe2fs -h /dev/sdb1 | grep "Filesystem state"
# Output: Filesystem state: clean with errors

# ============================================
# PART 4: DRY RUN (NO MODIFICATIONS)
# ============================================

# -n: check only, report inconsistencies.
sudo fsck -n /dev/sdb1
# Output: Inode 1234 has illegal block(s).

# ============================================
# PART 5: INTERACTIVE REPAIR (EXT4)
# ============================================

# Answer prompts for each inconsistency.
sudo fsck /dev/sdb1
# Prompt: Fix? yes/no

# ============================================
# PART 6: AUTOMATIC REPAIR (EXT4)
# ============================================

# -y: answer yes to all prompts.
sudo fsck -y /dev/sdb1

# ============================================
# PART 7: XFS DRY RUN
# ============================================

# XFS uses xfs_repair, not fsck.
sudo xfs_repair -n /dev/sdc1
# Output: Phase 1: Find and verify superblock...

# ============================================
# PART 8: XFS REPAIR
# ============================================

# Run the repair after reviewing the dry run.
sudo xfs_repair /dev/sdc1

# ============================================
# PART 9: FORCE ROOT FILESYSTEM CHECK
# ============================================

# Schedule a check on next boot.
sudo tune2fs -C 1 /dev/sda1
# Or use the kernel parameter: fsck.mode=force

The nine parts trace the full workflow: identify the filesystem, unmount it, check the superblock state, perform a dry run, run the repair, and handle the root filesystem case. The XFS path diverges at the repair command, but the overall sequence is the same.

Quick Reference

fsck Commands by Filesystem

Filesystem	Dry Run	Repair
ext4	`fsck -n /dev/sdX`	`fsck -y /dev/sdX`
XFS	`xfs_repair -n /dev/sdX`	`xfs_repair /dev/sdX`
Btrfs	`btrfs check --readonly /dev/sdX`	`btrfs check --repair /dev/sdX`

fsck Flags

Flag	Purpose
`-n`	Read-only, no modifications
`-y`	Answer yes to all prompts
`-f`	Force check even if clean
`-v`	Verbose output

Root Filesystem Check Methods

Method	Command
Force on next boot (ext4)	`tune2fs -C 1 /dev/sda1`
Kernel parameter	`fsck.mode=force`
Rescue mode	Boot live USB, unmount, run fsck

Best Practices

✅ Do This:

sudo umount /mnt/data
sudo fsck -n /dev/sdb1

✅ Always unmount and dry-run before repairing

sudo dumpe2fs -h /dev/sdb1 | grep "Filesystem state"

✅ Check the superblock state before deciding on repair

sudo xfs_repair -n /dev/sdc1
sudo xfs_repair /dev/sdc1

✅ Use the correct tool for XFS

❌ Don’t Do This:

sudo fsck /dev/sda1

❌ Never run fsck on a mounted filesystem

sudo fsck.xfs /dev/sdc1

❌ fsck.xfs does nothing; use xfs_repair

sudo fsck -y /dev/sdb1

❌ Automatic repair without a backup or dry run

Common Pitfalls

Pitfall	Why It Happens	Fix
Running fsck on mounted filesystem	Forgetting to unmount	Unmount first; use `df -Th` to verify
Using fsck on XFS	Assuming fsck is universal	Use `xfs_repair` for XFS
Data loss during repair	`-y` answers yes to everything	Use `-n` first; review output
Cannot repair root filesystem	Cannot unmount while running	Boot rescue media or force check at boot
Ignoring “clean with errors”	Assuming clean means healthy	Run fsck; the superblock knows about problems

Real-World Examples

1. Check ext4 State

sudo dumpe2fs -h /dev/sdb1 | grep "Filesystem state"

2. Dry Run ext4

sudo fsck -n /dev/sdb1

3. Interactive Repair ext4

sudo fsck /dev/sdb1

4. Automatic Repair ext4

sudo fsck -y /dev/sdb1

5. XFS Dry Run

sudo xfs_repair -n /dev/sdc1

6. XFS Repair

sudo xfs_repair /dev/sdc1

7. Clear XFS Log (Data Loss)

sudo xfs_repair -L /dev/sdc1

8. Force Root Check on Boot

sudo tune2fs -C 1 /dev/sda1

9. Mount After Repair

sudo mount /dev/sdb1 /mnt/data

10. Check lost+found

ls -la /mnt/data/lost+found/

Visual

fsck Decision Flow

┌──────────────────────────────────────────────┐
│  Filesystem error detected                   │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Identify filesystem type                    │
│  sudo blkid /dev/sdX                         │
└──────────┬───────────────────────┬───────────┘
           │ ext4                  │ XFS
           ▼                       ▼
┌──────────────────────┐  ┌──────────────────────┐
│  Unmount             │  │  Unmount             │
│  fsck -n             │  │  xfs_repair -n       │
│  Review output       │  │  Review output       │
│  fsck -y or fsck     │  │  xfs_repair          │
└──────────────────────┘  └──────────────────────┘
           │                       │
           ▼                       ▼
┌──────────────────────────────────────────────┐
│  Mount and verify                           │
└──────────────────────────────────────────────┘

The dry run is the safety checkpoint. It reveals the damage without committing to a repair that may discard data.

Root Filesystem Handling

┌──────────────────────────────────────────────┐
│  Root filesystem corruption suspected        │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Can the system boot?                        │
└──────────┬───────────────────────┬───────────┘
           │ YES                   │ NO
           ▼                       ▼
┌──────────────────────┐  ┌──────────────────────┐
│  tune2fs -C 1        │  │  Boot from live USB  │
│  reboot              │  │  unmount root        │
│  fsck runs on boot   │  │  fsck /dev/sdaX      │
└──────────────────────┘  └──────────────────────┘

The rescue path is the only option when the root filesystem cannot be mounted.

Summary

Item	Value
ext4 checker	`e2fsck` (via `fsck`)
XFS checker	`xfs_repair` (not `fsck.xfs`)
Dry run ext4	`fsck -n /dev/sdX`
Dry run XFS	`xfs_repair -n /dev/sdX`
Auto repair ext4	`fsck -y /dev/sdX`
XFS log clear	`xfs_repair -L /dev/sdX`
Root check trigger	`tune2fs -C 1 /dev/sdaX`
Filesystem state	`dumpe2fs -h`

Key takeaways:

fsck is a frontend, not a single tool. It dispatches to e2fsck for ext4 and other filesystem-specific checkers, but XFS requires xfs_repair directly .
Unmount before repairing. Running fsck on a mounted filesystem is unsafe and can cause further corruption .
Dry run first. The -n flag performs a read-only scan. Review the output before committing to a repair that may delete files .
“Clean with errors” is not clean. The superblock knows about a problem. Run fsck to resolve it before the filesystem corrupts further data .
XFS has its own repair model. xfs_repair operates in phases, and the -L flag clears the log at the cost of losing uncommitted transactions .
The root filesystem requires special handling. Force a check at boot with tune2fs -C 1 or fsck.mode=force, or boot from rescue media to repair it offline .

Remember: Filesystem integrity is a recovery discipline. The commands are simple—fsck, xfs_repair, dumpe2fs—but the consequences of running them incorrectly are severe. Always unmount, always dry-run, and always back up before a repair. The filesystem may be corrupted, but the data on it is not yet lost. The repair process is what determines whether it stays that way.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!