fsckCheck and repair a filesystem
fsck checks a filesystem's metadata for inconsistencies and repairs them: wrong free counts, orphaned inodes, broken directory entries. It runs on unmounted filesystems, automatically at boot when needed, and by hand after a crash or I/O errors.
fsck [-t TYPE] [OPTIONS] DEVICE (runs fsck.ext4 = e2fsck, fsck.xfs ...)After I/O errors in the logs you want to check /data, and you try it straight away.
sudoNeeds root to read and write the raw device.
fsck itself only finds the type (from blkid or /etc/fstab) and runs fsck.TYPE. For ext4 that's e2fsck, which opens the device and reads the superblock. If the filesystem is marked clean, and has no journal to replay, it stops after one line unless you pass -f. Otherwise it replays the journal and runs five passes: 1) scan every inode, its block map or extent tree, and the blocks it claims; 2) read every directory and check its entries; 3) make sure every directory is reachable from the root; 4) compare each inode's link count with the number of names pointing to it, putting unattached inodes into lost+found; 5) compare the block and inode bitmaps and free counts with what it found. Repairs are written straight to the device, so checking a mounted read-write filesystem would corrupt it. The exit code is a bit mask: 0 clean, 1 errors corrected, 4 errors left, 8 operational error. fsck.xfs does nothing; XFS uses xfs_repair.
-nCheck only: open read-only and answer no to everything-yAssume yes to all repairs (unattended)-p / -aPreen: fix only safe problems automatically, stop on serious ones (used at boot)-fForce a check even if the filesystem is marked clean-b SUPERBLOCKe2fsck: use a backup superblock (32768, 98304...)-C 0Show a progress bar-NDry run of the front end: show which checker would run-ACheck all filesystems in /etc/fstab, in pass orderxfs_repair -n DEVXFS: check without modifying (xfs_repair DEV to repair)sudo fsck -y /dev/nvme0n1p1 on the running root filesystemRepairing a mounted filesystem corrupts it: the kernel and e2fsck both write metadata without knowing about each other.
Check root from a rescue instance (attach the volume elsewhere) or let systemd-fsck run at bootRunning mke2fs without -n to find backup superblocksWithout -n mke2fs creates a brand-new empty filesystem over your data.
sudo mke2fs -n /dev/nvme3n1 (or dumpe2fs /dev/nvme3n1 | grep -i superblock if readable)fsck.xfs on an XFS volume and trusting its silencefsck.xfs is a no-op that always succeeds.
sudo xfs_repair -n /dev/nvme2n1, then xfs_repair to fixRepairing a failing disk in place without a copyfsck on hardware that returns I/O errors can make things worse, and its repairs can't be undone.
Snapshot the EBS volume (or ddrescue the disk) first, then repair the copyTry these on a Linux machine of your own. Each task has a hint and a solution.
Create an ext4 image file and run a forced, read-only check on it.
Damage the primary superblock of fs.img and repair it from a backup.
Find out which checker fsck would run for fs.img without running it.
fsckCheck and repair a filesystem
fsck checks a filesystem's metadata for inconsistencies and repairs them: wrong free counts, orphaned inodes, broken directory entries. It runs on unmounted filesystems, automatically at boot when needed, and by hand after a crash or I/O errors.
fsck [-t TYPE] [OPTIONS] DEVICE (runs fsck.ext4 = e2fsck, fsck.xfs ...)After I/O errors in the logs you want to check /data, and you try it straight away.
sudoNeeds root to read and write the raw device.
fsck itself only finds the type (from blkid or /etc/fstab) and runs fsck.TYPE. For ext4 that's e2fsck, which opens the device and reads the superblock. If the filesystem is marked clean, and has no journal to replay, it stops after one line unless you pass -f. Otherwise it replays the journal and runs five passes: 1) scan every inode, its block map or extent tree, and the blocks it claims; 2) read every directory and check its entries; 3) make sure every directory is reachable from the root; 4) compare each inode's link count with the number of names pointing to it, putting unattached inodes into lost+found; 5) compare the block and inode bitmaps and free counts with what it found. Repairs are written straight to the device, so checking a mounted read-write filesystem would corrupt it. The exit code is a bit mask: 0 clean, 1 errors corrected, 4 errors left, 8 operational error. fsck.xfs does nothing; XFS uses xfs_repair.
-nCheck only: open read-only and answer no to everything-yAssume yes to all repairs (unattended)-p / -aPreen: fix only safe problems automatically, stop on serious ones (used at boot)-fForce a check even if the filesystem is marked clean-b SUPERBLOCKe2fsck: use a backup superblock (32768, 98304...)-C 0Show a progress bar-NDry run of the front end: show which checker would run-ACheck all filesystems in /etc/fstab, in pass orderxfs_repair -n DEVXFS: check without modifying (xfs_repair DEV to repair)sudo fsck -y /dev/nvme0n1p1 on the running root filesystemRepairing a mounted filesystem corrupts it: the kernel and e2fsck both write metadata without knowing about each other.
Check root from a rescue instance (attach the volume elsewhere) or let systemd-fsck run at bootRunning mke2fs without -n to find backup superblocksWithout -n mke2fs creates a brand-new empty filesystem over your data.
sudo mke2fs -n /dev/nvme3n1 (or dumpe2fs /dev/nvme3n1 | grep -i superblock if readable)fsck.xfs on an XFS volume and trusting its silencefsck.xfs is a no-op that always succeeds.
sudo xfs_repair -n /dev/nvme2n1, then xfs_repair to fixRepairing a failing disk in place without a copyfsck on hardware that returns I/O errors can make things worse, and its repairs can't be undone.
Snapshot the EBS volume (or ddrescue the disk) first, then repair the copyTry these on a Linux machine of your own. Each task has a hint and a solution.
Create an ext4 image file and run a forced, read-only check on it.
Damage the primary superblock of fs.img and repair it from a backup.
Find out which checker fsck would run for fs.img without running it.