11.2. Filesystem-Specific Information for fsck

11.2.1. ext2, ext3, and ext4

All of these filesytems use the e2fsck binary to perform filesystem checks and repairs. The filenames fsck.ext2, fsck.ext3, and fsck.ext4 are hardlinks to this same binary. These binaries are run automatically at boot time and their behavior differs based on the filesystem being checked and the state of the filesystem.
A full filesystem check and repair is invoked for ext2, which is not a metadata journaling filesystem, and for ext4 filesystems without a journal.
For ext3 and ext4 filesystems with metadata journaling, the journal is replayed in userspace and the binary exited. This is the default action as journal replay ensures a consistent filesystem after a crash.
If these filesystems encounter metadata inconsistencies while mounted, they will record this fact in the filesystem super block. If e2fsck finds that a filesystem is marked with such an error e2fsck will perform a full check after replaying the journal (if present).
e2fsck may ask for user input during the run if the -p option is not specified. The -p option tells e2fsck to automatically do all repairs that may be done safely. If user intervention is required, e2fsck will indicate the unfixed problem in its output and reflect this status in the exit code.
Commonly used e2fsck run-time options include:
-n
No-modify mode. Check-only operation.
-b superblock
Specify block number of an alternate suprerblock if the primary one is damaged.
-f
Force full check even if the superblock has no recorded errors.
-j journal-dev
Specify the external journal device, if any.
-p
Automatically repair or "preen" the filesystem with no user input.
-y
Assume an answer of "yes" to all questions.
All options for e2fsck are specified in the e2fsck(8) manual page.
The following five basic phases are performed by e2fsck while running:
  1. Inode, block, and size checks.
  2. Directory structure checks.
  3. Directory connectivity checks.
  4. Reference count checks.
  5. Group summary info checks.
The e2image(8) utility can be used to create a metadata image prior to repair for diagnostic or testing purposes. The -r option should be used for testing purposes in order to create a sparse file of the same size as the filesystem itself. e2fsck can then operate directly on the resulting file. The -Q option should be specified if the image is to be archived or provided for diagnostic. This creates a more compact file format suitable for transfer.

11.2.2. XFS

No repair is performed automatically at boot time. To initiate a filesystem check or repair, the xfs_repair tool is used.

Note

Although an fsck.xfs binary is present in the xfsprogs package, this is present only to satisfy initscripts that look for an fsck.filesystem binary at boot time. fsck.xfs immediately exits with an exit code of 0.
Another thing to be aware of is that older xfsprogs packages contain an xfs_check tool. This tool is very slow and does not scale well for large filesystems. As such, it has been depreciated in favor of xfs_repair -n.
A clean log on a filesystem is required for xfs_repair to operate. If the filesystem was not cleanly unmounted, it should be mounted and unmounted prior to using xfs_repair. If the log is corrupt and cannot be replayed, the -L option may be used to zero the log.

Important

The -L option must only be used if the log cannot be replayed. The option discards all metadata updates in the log and will result in further inconsistencies.
It is possible to run xfs_repair in a dry run, check-only mode by using the -n option. No changes will be made to the filesystem when this option is specified.
xfs_repair takes very few options. Commonly used options include:
-n
No modify mode. Check-only operation.
-L
Zero metadata log. Use only if log cannot be replayed with mount.
-m maxmem
Limit memory used during run to maxmem MB. 0 can be specified to obtain a rough estimate of the minimum memory required.
-l logdev
Specify the external log device, if present.
All options for xfs_repair are specified in the xfs_repair(8) manual page.
The following eight basic phases are performed by xfs_repair while running:
  1. Inode and inode blockmap (addressing) checks.
  2. Inode allocation map checks.
  3. Inode size checks.
  4. Directory checks.
  5. Pathname checks.
  6. Link count checks.
  7. Freemap checks.
  8. Super block checks.
These phases, as well as messages printed during operation, are documented in depth in the xfs_repair(8) manual page.
xfs_repair is not interactive. All operations are performed automatically with no input from the user.
If it is desired to create a metadata image prior to repair for diagnostic or testing purposes, the xfs_metadump(8) and xfs_mdrestore(8) utilities may be used.

11.2.3. Btrfs

Note

Btrfs is available as a Technology Preview feature in Red Hat Enterprise Linux 7 but has been deprecated since the Red Hat Enterprise Linux 7.4 release. It will be removed in a future major release of Red Hat Enterprise Linux.
For more information, see Deprecated Functionality in the Red Hat Enterprise Linux 7.4 Release Notes.
The btrfsck tool is used to check and repair btrfs filesystems. This tool is still in early development and may not detect or repair all types of filesystem corruption.
By default, btrfsck does not make changes to the filesystem; that is, it runs check-only mode by default. If repairs are desired the --repair option must be specified.
The following three basic phases are performed by btrfsck while running:
  1. Extent checks.
  2. Filesystem root checks.
  3. Root reference count checks.
The btrfs-image(8) utility can be used to create a metadata image prior to repair for diagnostic or testing purposes.