fsck

The Linuxvox fsck reference provides a concise definition: “fsck (short for ‘File System Check’) is a utility that scans Linux file systems for inconsistencies and repairs them. It is part of the util-linux package, preinstalled on most Linux distributions. File systems (e.g., ext4, XFS, Btrfs) rely on metadata (inode tables, superblocks, etc.) to track files and directories. When a system shuts down improperly (e.g., power loss), or due to hardware issues (e.g., bad sectors), this metadata can become corrupted. fsck identifies such corruption (e.g., orphaned inodes, bad blocks, or mismatched file counts) and attempts to fix it.”¹

The Unix philosophy origin

fsck dates back to early Unix (V7 in 1979) and reflects classic Unix design principles: small, focused tools that compose well rather than monolithic utilities. Key historical points:

• 1979 (Unix V7): original fsck for the Bell Labs Unix file system; fixed inode and directory structure consistency.
• 1980s BSD Unix: fsck adapted for Berkeley FFS (Fast File System) which became the model for many later filesystems.
• 1992 (Linux 0.99): Linux inherited the fsck pattern; e2fsck developed for ext2 by Theodore Ts’o.
• 1990s-2000s: filesystem-specific tools proliferated as new filesystems emerged (XFS, ReiserFS, JFS, Btrfs).
• Modern systemd era: systemd-fsck@.service unit handles boot-time invocation.
• util-linux package: the canonical home for fsck.c since 2002; bundled with virtually all Linux distributions.

When fsck runs automatically

Linux systems trigger fsck automatically in several scenarios. The Linuxize fsck reference describes the trigger conditions: “On most Linux distributions, fsck runs at boot time if a filesystem is marked as dirty or after a certain number of boots or time.” Specific triggers:

• Dirty bit set: filesystem was not unmounted cleanly (power loss, kernel crash, force shutdown).
• Mount count threshold: tune2fs -c configures the maximum mount count after which fsck runs.
• Time interval: tune2fs -i configures the maximum time between checks (e.g., 2w for 2 weeks).
• /forcefsck flag file: creating this file in the root triggers fsck on next boot.
• fsck.mode=force kernel parameter: GRUB-level option to force fsck on every boot.
• systemd-fsck@.service: the systemd unit that handles boot-time checking.

The /etc/fstab pass field

The OneUptime fsck reference describes the fstab integration: “In /etc/fstab, the last two fields control fsck: <fs> <mount> <type> <options> <dump> <pass>. Pass field values: 0 – Never check; 1 – Check first (root filesystem); 2 – Check after root (other filesystems).”² The semantics:

• Pass 0: never check; appropriate for swap partitions, btrfs filesystems, XFS filesystems (which don’t use traditional fsck), and network mounts.
• Pass 1: check first; reserved for the root filesystem, so other checks don’t interfere with root recovery.
• Pass 2: check after root; standard for non-root ext filesystems and FAT mounts.
• Parallel checks: filesystems with the same pass number are checked in parallel, accelerating boot for systems with many filesystems.

The exit code spectrum

fsck returns specific exit codes that indicate the operation result; useful for scripts and automation:

Code	Meaning	Action needed
0	No errors	None
1	Errors corrected	None; filesystem now clean
2	System should be rebooted	Reboot the system
4	Errors left uncorrected	Manual intervention required
8	Operational error	Check syntax and device existence
16	Usage or syntax error	Review command parameters
32	fsck canceled by user	Re-run if check still needed
128	Shared library error	System library issue

Privileges and execution requirements

fsck has specific execution requirements:

• Root privileges required: sudo or root account; fsck modifies block devices and metadata.
• Filesystem must be unmounted: the only safe exception is fsck -n (read-only diagnostic).
• Root filesystem requires special handling: single-user mode, recovery mode, live USB, or boot-time check.
• LVM volumes: activate with lvchange -ay if inactive; otherwise fsck operates normally on /dev/vg/lv paths.
• Encrypted volumes: must be unlocked (cryptsetup luksOpen) before fsck can access the filesystem.

The wrapper architecture is fsck’s defining design choice and the most significant departure from chkdsk’s monolithic approach. Understanding the dispatch logic clarifies which actual tool runs in different scenarios.

The dispatch logic

The OneUptime Ubuntu fsck reference describes the wrapper behavior: “fsck is actually a wrapper that calls the appropriate filesystem-specific tool: # fsck dispatches to the right tool automatically sudo fsck /dev/sdb1 # Checks whatever filesystem is on sdb1.”³ The dispatch process:

1. fsck examines the device’s filesystem signature (typically via blkid or libblkid).
2. Based on the detected type, fsck looks up the corresponding fsck.<type> binary.
3. fsck.ext2, fsck.ext3, fsck.ext4 → all symlinks to e2fsck.
4. fsck.xfs → no-op script that points to xfs_repair.
5. fsck.btrfs → no-op script that points to btrfs check.
6. fsck.vfat / fsck.fat / dosfsck → handles FAT12/16/32.
7. fsck.exfat → handles exFAT (separate package).
8. fsck.ntfs → typically symlink to ntfsfix from ntfs-3g.

The filesystem-tool mapping

Filesystem	Wrapper	Real tool	Repair semantics
ext2	fsck.ext2	e2fsck	Full 5-pass scan
ext3	fsck.ext3	e2fsck	Journal replay + 5-pass
ext4	fsck.ext4	e2fsck	Journal replay + 5-pass
XFS	fsck.xfs	xfs_repair (separate)	Journal replay + B-tree check
Btrfs	fsck.btrfs	btrfs check (separate)	COW-aware check (use with care)
NTFS	fsck.ntfs	ntfsfix	Limited NTFS repair via ntfs-3g
FAT12/16/32	fsck.vfat / fsck.fat	dosfsck	FAT chain repair
exFAT	fsck.exfat	exfatfsck	exFAT structure check
HFS+ (macOS)	fsck_hfs	fsck_hfs	macOS-native
APFS (macOS)	fsck_apfs	fsck_apfs	macOS-native

Common fsck command patterns

Several command patterns are commonly used in practice:

• sudo fsck /dev/sdb1: auto-detect filesystem and run interactive check.
• sudo fsck -n /dev/sdb1: read-only diagnostic; safe on mounted filesystems with limitations.
• sudo fsck -y /dev/sdb1: automatic yes to all repair prompts; use with caution.
• sudo fsck -p /dev/sdb1: automatically repair only safe issues; safer than -y.
• sudo fsck -f /dev/sdb1: force check even if filesystem is marked clean.
• sudo fsck -A: check all filesystems in /etc/fstab.
• sudo fsck -AR: check all but skip root filesystem.
• sudo fsck -fy /dev/sdb1: force check with yes-to-all; common comprehensive repair invocation.

The interactive vs automatic distinction

The e2fsck man page describes the interactive mode: “If e2fsck is run in interactive mode (meaning that none of -y, -n, or -p are specified), the program will ask the user to fix each problem found in the file system. A response of ‘y’ will fix the error; ‘n’ will leave the error unfixed; and ‘a’ will fix the problem and all subsequent problems; pressing Enter will proceed with the default response, which is printed before the question mark.”⁴ The three modes:

• Interactive (default): prompts for each issue; appropriate for careful manual repair where the operator can review each decision.
• -p (preserve): automatically fixes only “safe” issues; more conservative than -y; recommended for boot-time runs.
• -y (yes to all): automatically fixes all issues including potentially destructive ones; fastest but riskiest.
• -n (no, read-only): reports issues without fixing; safe for diagnosis and for limited use on mounted filesystems.

Boot-time fsck via systemd

Modern Linux distributions use systemd-fsck@.service for boot-time integration:

• systemd-fsck-root.service: handles the root filesystem before mount.
• systemd-fsck@.service: templated service for non-root filesystems based on /etc/fstab.
• Configuration via /etc/fstab: the pass field controls which filesystems are checked.
• fsck.mode kernel parameter: auto (default), force, or skip.
• fsck.repair kernel parameter: preen (default, equivalent to -p), yes (-y), or no (don’t auto-repair).
• Boot output: systemd routes fsck output to the system journal; visible via journalctl.

e2fsck is the most commonly invoked filesystem-specific tool because ext4 is the default filesystem on most Linux distributions. The 5-pass scan structure is well-documented and characteristic of ext family checks.

The five-pass structure

The Hopeness Medium e2fsck reference shows the typical scan output: “Pass 1: Checking inodes, blocks, and sizes / Pass 2: Checking directory structure / Pass 3: Checking directory connectivity / Pass 4: Checking reference counts / Pass 5: Checking group summary information.”⁵ Each pass targets a specific consistency aspect:

Pass	Focus	What it checks
1	Inodes, blocks, sizes	Inode validity, block pointers, file sizes, shared blocks
2	Directory structure	Directory inode entries, ‘.’ and ‘..’, filename validity
3	Directory connectivity	All directories trace back to root; orphans go to lost+found
4	Reference counts	Inode link counts match directory entries
5	Group summary information	Block bitmap, inode bitmap, group descriptor accuracy

The journal replay shortcut

The e2fsck man page describes a key optimization for ext3/ext4: “For ext3 and ext4 filesystems that use a journal, if the system has been shut down uncleanly without any errors, normally, after replaying the committed transactions in the journal, the file system should be marked as clean. Hence, for filesystems that use journalling, e2fsck will normally replay the journal and exit, unless its superblock indicates that further checking is required.” The optimization:

• After unclean shutdown, e2fsck checks the journal first.
• If journal contains uncommitted transactions, they’re replayed to the filesystem.
• If the superblock indicates the filesystem is otherwise consistent, e2fsck exits without running the 5-pass scan.
• This makes most boot-time fsck runs near-instant on healthy ext4 filesystems.
• The full 5-pass scan only runs when the journal replay isn’t sufficient or when -f forces it.

Pass 1: inode and block verification

Pass 1 is typically the longest pass on large filesystems:

• Reads each inode in the filesystem (typically millions on a multi-TB drive).
• Verifies inode metadata: type (file, directory, symlink), permissions, timestamps.
• Checks block pointers within filesystem bounds.
• Detects shared blocks: same block claimed by multiple inodes (corruption).
• Verifies file sizes match block allocations.
• Reports per-issue: “Inode X has illegal block(s)” and similar diagnostics.

Pass 2: directory structure

Pass 2 verifies directory contents and structure:

• Reads each directory inode and walks its entries.
• Verifies ‘.’ (self) and ‘..’ (parent) entries are present and correct.
• Checks filename validity (length, character set).
• Verifies inode references in directory entries point to valid inodes.
• Detects duplicate entries within a single directory.
• For htree-indexed directories, validates the index structure.

Pass 3: directory connectivity

Pass 3 ensures the directory tree is connected:

• Starting from the root inode, traces all directory paths.
• Identifies disconnected directories (those not reachable from root).
• Reconnects orphan directories to lost+found.
• Detects directory loops (a directory containing itself).

Pass 4: reference counts

Pass 4 verifies inode link counts:

• For each inode, counts directory entries pointing to it.
• Compares with the inode’s stored link count.
• Corrects mismatches.
• Identifies inodes with 0 actual references that should be deleted.

Pass 5: group summary

Pass 5 verifies the bitmap and group descriptor accuracy:

• Verifies block bitmap matches actual allocated blocks.
• Verifies inode bitmap matches actual used inodes.
• Verifies group descriptor counts (free blocks, free inodes, used directories).
• Updates summary information if mismatches found.

e2fsck-specific parameters

Beyond the standard fsck parameters, e2fsck has ext-specific options:

• -c (badblocks): invokes badblocks(8) for a read-only scan; bad blocks added to bad block inode.
• -cc (badblocks RW): non-destructive read-write badblocks scan; more thorough.
• -b superblock: use alternate superblock (typically 32768, 98304, 163840, etc.).
• -B blocksize: force specific blocksize when locating superblock.
• -D: optimize directories (reindex htree directories).
• -E: set extended options (e.g., -E discard for SSD trim).
• -l filename / -L filename: add bad blocks from file (-l) or replace bad block list (-L).

Alternate superblock recovery

When the primary superblock is corrupted, e2fsck can use backup copies. The OneUptime fsck reference describes the recovery procedure: “If the ext4 superblock is corrupted, fsck will report it and offer to use a backup: # Find backup superblock locations sudo mke2fs -n /dev/sdb1 # Dry run shows superblock locations without formatting.” Typical backup locations: 32768, 98304, 163840, 229376, 294912 (for default 4K blocks). The recovery sequence: sudo e2fsck -b 32768 /dev/sdb1.

While ext is the most common Linux filesystem, fsck must handle several others. Each has distinct repair semantics that affect how recovery scenarios play out.

XFS: xfs_repair as the real tool

The Linuxize fsck reference summarizes the XFS situation: “fsck does not repair XFS or Btrfs. Use the filesystem-specific tool. XFS uses xfs_repair, and Btrfs usually uses btrfs scrub or btrfs check.”⁶ The XFS-specific workflow:

• fsck.xfs: no-op script that prints “see xfs_repair(8)” and exits.
• xfs_repair -n /dev/sdb1: read-only check; identifies issues without modifying.
• xfs_repair /dev/sdb1: full repair; filesystem must be unmounted.
• xfs_repair -L /dev/sdb1: clear log; last resort when xfs_repair fails with “dirty log” error; risks data loss.
• Mount-time journal replay: XFS replays its journal automatically when mounted; xfs_repair handles deeper corruption.
• B-tree-based metadata: XFS uses B-trees rather than the inode-table model of ext; xfs_repair logic differs accordingly.
• fstab pass=0: XFS filesystems should have fstab pass=0 to prevent boot-time fsck attempts.

Btrfs: scrub vs check vs repair

Btrfs has the most complex relationship with fsck because of its copy-on-write architecture. The fsck.btrfs man page describes the design: “fsck.btrfs is a type of utility that should exist for any filesystem and is called during system setup when the corresponding /etc/fstab entries contain non-zero value for fs_passno… Traditional filesystems need to run their respective fsck utility in case the filesystem was not unmounted cleanly and the log needs to be replayed before mount. This is not needed for BTRFS. You should set fs_passno to 0.”⁷ The Btrfs ecosystem:

• fsck.btrfs: no-op that prints “see btrfs(8) subcommand check” and exits.
• btrfs scrub: the active maintenance tool; reads all data and metadata, verifying checksums; runs on mounted filesystems.
• btrfs check –readonly /dev/sdb1: safe diagnostic; identifies issues without modifying.
• btrfs check –repair /dev/sdb1: dangerous repair mode; can cause additional corruption; last resort.
• btrfs rescue: emergency tools (zero-log, super-recover, chunk-recover) for severe corruption.
• Snapshots as recovery: the preferred Btrfs recovery is to roll back to an earlier snapshot rather than use –repair.
• Recovery mount options: rescue=usebackuproot, recovery, etc., for emergency mounting.

FAT family: dosfsck

FAT12, FAT16, and FAT32 are handled by dosfsck (also accessible as fsck.vfat or fsck.fat):

• fsck.vfat /dev/sdb1: standard invocation for FAT volumes.
• -a: automatic repair (safer than -y for FAT).
• -r: interactive repair with prompts.
• -w: write changes immediately to disk during repair.
• -V: verify after repair by re-reading.
• FAT-specific issues: cluster chain corruption, FAT/FAT2 inconsistency, lost clusters, cross-linked files.
• FOUND.000 equivalent: FAT recovery doesn’t use lost+found; instead places lost clusters in FILE0001, FILE0002 in root.

exFAT: exfatfsck

exFAT (used on SD cards and USB drives over 32GB) has its own checker:

• fsck.exfat /dev/sdb1: from the exfatprogs package (modern) or exfat-utils (legacy).
• Limited functionality: exFAT repair tools are less mature than ext or NTFS counterparts.
• Cross-platform considerations: exFAT volumes may be checked on Windows or macOS instead.

NTFS: ntfsfix

NTFS support on Linux is via the ntfs-3g package; the fsck-equivalent is ntfsfix:

• ntfsfix /dev/sdb1: basic NTFS repair via ntfs-3g.
• Limited compared to chkdsk: ntfsfix handles common issues but isn’t a full chkdsk replacement.
• Use case: primarily clears the dirty bit and fixes minor inconsistencies so the volume can be mounted.
• For serious NTFS repair: mount the drive on Windows and use chkdsk; ntfsfix is a stopgap.
• fsck.ntfs: typically a symlink to ntfsfix on systems with ntfs-3g installed.

macOS fsck variants

On macOS, the fsck command exists but dispatches to macOS-specific filesystem tools:

• fsck_hfs: for HFS+ volumes (Mac OS Extended).
• fsck_apfs: for APFS volumes (modern Mac default).
• fsck_msdos: for FAT volumes.
• fsck_exfat: for exFAT volumes.
• Single-user mode: macOS allows fsck on root via Recovery Mode or single-user mode (Cmd+S at boot).
• Disk Utility: graphical front-end that invokes the appropriate fsck variant.

fsck has the same fundamental data recovery dynamics as chkdsk: it can both help and harm depending on the scenario. The Linux ecosystem provides additional tools that complement fsck for recovery workflows.

The image-first recovery workflow on Linux

The professional Linux recovery workflow:

1. Stop using the affected drive: unmount immediately if mounted; remount read-only if active access is needed.
2. Image the drive: use ddrescue (the standard Linux recovery imager) or HDDSuperClone for severely-damaged drives.
3. Verify the image: calculate hashes; ensure complete acquisition.
4. Run recovery against the image: use TestDisk, PhotoRec, ext4magic, extundelete, or specialized tools on the image file.
5. Save recovered files to a separate destination: never overwrite the original drive or its image.
6. Validate recovered data: check critical files for integrity.
7. Optionally run fsck on the original drive: only after recovery, to restore filesystem functionality for reuse.

The lost+found directory

fsck creates and uses a lost+found directory in the filesystem root for orphan files. The OneUptime fsck reference describes the convention: “When fsck finds orphaned files (files with no directory entry), it places them in the lost+found directory: # List lost+found contents ls -la /lost+found/ # Files are named by inode number # Example: #12345 is inode 12345.” Key properties:

• Located at the filesystem root (e.g., /lost+found/ or /home/lost+found/).
• Files named by inode number with # prefix (e.g., #12345).
• Original filenames are lost; only the data content survives.
• Uses the file utility to identify file types: file /lost+found/#12345.
• For text files, simple cat or less can reveal content; for binary files, signature analysis is needed.
• Created automatically by mke2fs when the filesystem is created; pre-allocates space.
• If lost+found is missing or full, mklost+found utility recreates it.

Linux-specific recovery tools

The Linux ecosystem has specialized recovery tools that complement fsck:

• ddrescue / dd_rescue: the standard Linux drive imaging tools; handle bad sectors gracefully.
• TestDisk: partition table repair and partition recovery.
• PhotoRec: file carving from images or drives; recovers files by signature regardless of filesystem.
• ext4magic: ext4-specific recovery using the journal to recover deleted files.
• extundelete: ext3/ext4 deleted file recovery using inode metadata.
• foremost / scalpel: file carving tools; alternatives to PhotoRec.
• debugfs: low-level ext filesystem debugger; manual inode and block manipulation.
• btrfs restore: Btrfs-specific recovery from damaged filesystems.
• xfs_db: XFS debugger for low-level access.
• R-Studio Linux / UFS Explorer: commercial cross-filesystem recovery tools.

Why fsck can harm recovery

The same metadata-modification risks apply to fsck as to chkdsk:

• Inode modifications: e2fsck may overwrite inode entries that recovery tools like ext4magic could otherwise use.
• Directory rebuilds: Pass 2 and Pass 3 may regenerate directory entries, losing pointers to deleted files.
• Journal replay: the journal contains recent metadata changes; replay commits them and overwrites previous state.
• Bitmap updates: Pass 5 modifies block and inode bitmaps; recovery tools may interpret freed inodes as reusable.
• Orphan reconnection: moving files to lost+found loses original filenames and directory context.
• Badblocks scan with -c: reads and potentially writes to questionable sectors; can stress failing drives.

When fsck is appropriate

Despite the risks, fsck has clear roles:

• Routine maintenance: periodic fsck on healthy drives via mount count or time interval.
• Post-crash recovery: automatic boot-time fsck after unclean shutdown.
• Post-recovery functionality restoration: after data has been recovered or written off, fsck restores filesystem usability.
• Fresh formatting validation: verifying integrity of newly-created filesystems.
• Pre-deployment checks: validating drives before production use.
• Read-only diagnostics: fsck -n is safe even on mounted filesystems for status reporting.

When fsck is dangerous

Specific scenarios where fsck should be avoided:

• Mounted filesystems: guaranteed corruption; the only safe exception is fsck -n.
• Drives with critical irreplaceable data and signs of corruption: recover first, then fsck.
• Failing or marginal hardware: badblocks scan with -c stresses already-weak drives.
• Btrfs filesystems with snapshots: btrfs check –repair can damage snapshot trees; rollback is preferred.
• XFS with dirty log: xfs_repair -L last resort only; clears journal and can lose recent changes.
• Encrypted volumes without backup: fsck on dm-crypt mappings can interact unpredictably with the underlying encrypted layer.