A server restarts in emergency mode, a partition refuses to mount, or the kernel reports ext4 errors. The temptation is to launch immediately fsck on the first device found. This is precisely what must be avoided: a repair on the wrong volume, or on a file system that is still mounted, can worsen the damage.
fsck is a launcher that calls the tool appropriate for the file system. Before any correction, you must identify the partition, verify its type, confirm that it is no longer in use, and keep a usable backup. I always start with a non-write check. Repair comes only after that.

Identify the partition and its file system
/dev/sdb1The disk order may change after a restart or adding a USB device. Display the file system type, UUID, model, serial number, and mount points:
lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS,MODEL,SERIAL,TYPE
sudo blkid
The guide to lsblk under Linux details this verification. If you are working with LVM, target the logical volume that contains the file system, for example /dev/mapper/vg_data-lv_archive, not the physical LVM volume located below. The article dedicated to LVM and its different layers
Next, check how the source is used:
findmnt --source /dev/nvme0n1p2
findmnt --target /mnt/data
An output indicates that the volume has increased. If there is no output, don’t be sure: reread the instructions. lsblk And findmnt File system UUID
Never repair a mounted file system
The kernel can modify metadata while fsck Try to correct them. The two views of the file system then become inconsistent. A read-only mount is not a sufficient guarantee for improvising a repair: the tool must be used under the conditions specified in its documentation.
For a given volume of data, stop the services that use it, exit the terminals located in its directory tree, and then unmount it:
sudo fuser -vm /mnt/data
sudo umount /mnt/data
findmnt --source /dev/nvme0n1p2
If It responds that the target is busy, do not force it. Identify the process with fuse Or lsofthen properly shut down the service in question.
For the root partition, use a live media or a rescue environment where this partition is not mounted. Simply switching to single-user or emergency mode does not prove that the root partition is unmounted. On a remote server, ensure a KVM console, IPMI, or the hosting provider’s emergency access is available before rebooting.
Start with a non-writing check
The following command shows which checker fsck
sudo fsck -N /dev/nvme0n1p2
On a disassembled ext2, ext3 or ext4 system, then run a forced scan, answering “no” to all proposed modifications:
sudo e2fsck -f -n /dev/nvme0n1p2
echo "Code e2fsck: $rc"
-n retains read-only control. The option -f A complete examination is required even if the file system appears clean. This check can be lengthy on a large volume. If the disk reports input/output errors, timeouts, or disconnections, first back up what is still readable and then check the hardware. fsck It repairs a logical structure, not a disk that physically fails.
Kernel messages can confirm this scenario:
sudo dmesg -T | grep -Ei 'I/O error|timeout|reset|EXT4-fs|XFS|BTRFS'
sudo journalctl -k -b -p warning..alert
The guide to dmesg and kernel errors helps to put these alerts back in the order of events.
Repairing an ext4 volume without answering yes everywhere
If the check reports inconsistencies, verify your backup, confirm the device again, and keep the volume unmounted. Then launch the interactive repair:
sudo e2fsck -f /dev/nvme0n1p2
Read each question before submitting. Avoid -y By default, this option accepts all repairs, even when the situation requires backing up the volume or examining the hardware before proceeding. On a large partition, blindly performing an automatic repair is a poor trade-off between speed and control.
When the command finishes, immediately capture its exit code:
rc=$?
echo "Code e2fsck: $rc"
Read the fsck exit code
A non-zero code does not always mean that the repair has failed. The main values are as follows:
zero: no errors detected;: errors corrected;two: errors corrected, restart required;four: uncorrected errors;eight: error in the tester’s operation;sixteen: usage or syntax error;thirty-two: control canceled;one hundred twenty-eight: error related to a shared library.
These values function like bits and can be added together. A code requires that the read/write volume not be increased as if everything were fixed. A code eight request to check the command, file system type, installed tools and displayed messages.
XFS and Btrfs use their own tools
fsck does not apply the same method to all file systems. For XFS, start with an unmodified scan of the unmounted volume:
sudo xfs_repair -n /dev/nvme0n1p2
xfs_repair, always off-mount. Do not use -L As a first attempt: resetting the log may result in a loss of recent metadata.
For Btrfs, the prudent control is explicitly read-only:
--repair without a backup and without a procedure adapted to the observed problem. The Btrfs documentation itself warns against using it without experienced guidance. Always check FSTYPE with lsblk -f before choosing the tool.
Check the volume before reassembling it
After an ext4 repair, run a non-write check. If the result is clean, remount the volume, then check the type, space, and new kernel messages:
sudo e2fsck -f -n /dev/nvme0n1p2
sudo mount /mnt/data
findmnt /mnt/data
df -hT /mnt/data
sudo journalctl -k -b -p warning..alert
For a root partition controlled at startup, also check the traces of the previous startup:
journalctl -b -1 | grep -Ei 'fsck|filesystem|I/O error|EXT4-fs|XFS|BTRFS'
systemctl --failed
There fsck man page describes the launcher and its exit codes. For ext4, see e2fsckThe procedures specific to XFS and to Btrfs must remain a priority over a generic command found at random.