fsck

Check filesystem /dev/sdXN, reporting any damaged blocks

$ sudo fsck [/dev/sdXN]

$ sudo fsck -r [/dev/sdXN]

$ sudo fsck -a [/dev/sdXN]

fsck [options] [filesystem...]

-A
    Checks all filesystems listed in /etc/fstab. Filesystems are checked in the order specified by their pass number in fstab.

-a
    Automatically repair filesystem errors without prompting. This option should be used with extreme caution as it might delete data.

-r
    Interactively repair filesystem errors. This prompts the user for confirmation on each detected issue.

-y
    Assume 'yes' to all questions asked by the filesystem-specific checker. Similar to -a, but more aggressive and less cautious.

-N
    Don't execute the check; merely show what would be done (a 'dry run').

-P
    When used with -A, check filesystems in parallel. This can speed up the process but should be used carefully.

-R
    When used with -A, skip checking the root filesystem (/). The root filesystem is typically checked automatically at boot time.

-S
    Serialize filesystem checks. Useful when checking multiple filesystems to avoid resource contention.

-t fstype
    Specify the filesystem type(s) to be checked (e.g., ext4, xfs, vfat). Multiple types can be specified in a comma-separated list.

-V
    Produce verbose output, showing more details about the checks being performed.

-C [fd]
    Display completion/progress bars for those filesystem checkers that support it. The optional fd specifies the file descriptor to send the progress info to.

-M
    Do not check mounted filesystems. This is a safety measure to prevent data corruption.

-F
    Force checking even if the filesystem appears clean. This overrides the clean flag often set by journaling filesystems.

The fsck (file system consistency check) command is a crucial utility used to check the consistency of a Linux filesystem and, if necessary, repair it. It's typically invoked when a filesystem becomes corrupted due to improper shutdowns, hardware failures, or software errors. fsck acts as a front-end for various filesystem-specific checker programs (e.g., fsck.ext4 for Ext4 filesystems, fsck.xfs for XFS). When executed, fsck examines the filesystem's metadata (superblock, inodes, directories, etc.) to ensure that its internal structure is consistent. If inconsistencies are found, it attempts to correct them, often by asking the user for confirmation (interactive mode) or by automatically applying fixes. Regular use, especially after an unclean shutdown, helps maintain data integrity and prevent data loss on disk partitions or volumes.

WARNING: Never run fsck on a mounted filesystem, especially if it's mounted read-write. Doing so can lead to severe data corruption and data loss. The filesystem must be unmounted or mounted read-only before running fsck. For the root filesystem (/), it is usually checked automatically by the init system during boot, or it may require booting from a live CD/USB to unmount it before checking.

fsck returns a bitmask of the following exit codes, which are useful for scripting:

• 0: No errors.
• 1: Filesystem errors corrected.
• 2: System should be rebooted.
• 4: Filesystem errors uncorrected.
• 8: Operational error (e.g., fsck process failed to run).
• 16: Usage or syntax error.
• 32: Fsck canceled by user request.
• 128: Shared library error.

It's important to understand that fsck is not the actual filesystem checker. Instead, it's a wrapper script or program that searches for the appropriate filesystem-specific checker (e.g., fsck.ext4, fsck.xfs) in your system's PATH (typically /sbin/). It then executes that specific checker, passing along the options and the filesystem device. This modular design allows fsck to support a wide variety of filesystem types without needing to be rewritten for each one.

The concept of filesystem checking dates back to early Unix systems, where utilities like checkfs and dcheck were used to verify filesystem integrity. The fsck command emerged as a standardized utility, evolving into a front-end that calls filesystem-specific checkers. Its design as a wrapper allowed it to adapt to various filesystem types as they were developed (e.g., ext2, ext3, ext4, XFS). While journaling filesystems (like Ext3, Ext4, XFS) have significantly reduced the frequency of requiring manual fsck runs after unclean shutdowns, the command remains an indispensable tool for diagnosing and repairing severe filesystem corruption.

mount(8), umount(8), fstab(5), badblocks(8), e2fsck(8), xfs_repair(8), mkfs(8)