Fixing a Corrupted ext4 or XFS Filesystem with fsck

Filesystem corruption on Linux — usually surfacing as mount failures, unexpected read-only remounts, or explicit kernel errors about filesystem inconsistency in dmesg — has a correct, sequential repair process, and the single most common way to make it worse is skipping straight to running a repair tool without first getting the filesystem into a safe state to be repaired.

Step one: unmount it, or boot from external media

Never run fsck (for ext4) or xfs_repair (for XFS) against a mounted, actively-in-use filesystem. Both tools assume exclusive access to the filesystem’s on-disk structures while repairing them, and a filesystem being simultaneously modified by running processes while a repair tool is rewriting its metadata is a recipe for making corruption meaningfully worse rather than fixing it.

For the root filesystem specifically, this means booting from a live/rescue environment (a USB installer’s rescue mode, or a distribution-specific rescue target) rather than attempting to repair root while it’s mounted and in active use by the running system:

umount /dev/sdb1

for a non-root filesystem you can simply unmount, or boot into rescue mode for anything that can’t be unmounted while running.

Reading dmesg first, to understand what kind of corruption you’re dealing with

Before running a repair tool, dmesg (or the last boot’s kernel log) usually contains the actual filesystem-level error that triggered the problem, which meaningfully informs what to expect from repair:

dmesg | grep -iE 'ext4|xfs|EXT4-fs|XFS'

A message about a specific inode, directory entry, or journal replay failure gives you a much more informed sense of the corruption’s scope before you commit to a repair pass, versus a vaguer “unable to mount” error that could indicate anything from trivial journal inconsistency to serious structural damage.

ext4: fsck in stages, not blindly with -y

For ext4, fsck.ext4 (invoked via the generic fsck wrapper) should generally be run first WITHOUT the automatic-yes flag, so you can actually see what it’s proposing to fix before it does so at scale:

fsck.ext4 -f /dev/sdb1

The -f forces a full check even if the filesystem appears clean according to its own mount-count/last-checked metadata, which matters specifically because a filesystem that was forcibly unmounted or crashed mid-write may not have its “needs checking” flag set correctly, and skipping the check based on that flag alone could miss exactly the corruption you’re trying to find. Reviewing the specific proposed fixes on a genuinely important filesystem, before blanket-approving everything with -y, is worth the extra time when the data matters — some proposed fixes (removing an inode entirely, for instance) are destructive in a way you’d want to understand rather than approve reflexively.

Once you understand the scope, -y automates approval for a full repair pass:

fsck.ext4 -fy /dev/sdb1

XFS: a fundamentally different repair philosophy

XFS’s repair tool, xfs_repair, works differently from fsck.ext4 in a way that matters for how you approach it. XFS relies heavily on its own internal journal (the log) for consistency, and xfs_repair’s default behavior is to first replay that log to bring the filesystem back to a consistent state using the journal itself, before attempting any deeper structural repair:

xfs_repair /dev/sdb1

If the filesystem is too damaged for even log replay to succeed, xfs_repair will explicitly instruct you to zero the log instead — and critically, this is a step you should only take if xfs_repair itself asks for it, not a step to jump to preemptively, since zeroing the log discards whatever the journal was tracking and should only happen after normal log-replay repair has genuinely been ruled out as insufficient:

xfs_repair -L /dev/sdb1

-L (zero the log) is explicitly a fallback for the case where log replay itself is impossible, and using it as a default first attempt rather than a directed fallback risks discarding recoverable journal information unnecessarily.

When the repair tool reports unrecoverable corruption

If fsck.ext4 or xfs_repair completes but reports it moved damaged files into lost+found, or reports data loss it couldn’t avoid, the corruption exceeded what automated repair could reconstruct — this is the tool being honest about a limitation, not a sign it did something wrong. At this point, the practical path is: check lost+found for recovered file fragments (often named by inode number rather than original filename, requiring manual identification based on content), and if the affected data matters and no backup exists, this may be the point to stop attempting further filesystem-level repair and consider whether specialized data-recovery tooling working at the block level (rather than the filesystem-structure level fsck/xfs_repair operate at) has anything further to offer — a meaningfully more involved and less certain process than a straightforward fsck repair.

Confirming the fix and remounting

After a successful repair, re-run the check tool once more in read-only/check-only mode (without the repair flag) to confirm no further inconsistencies are reported before remounting for normal use:

fsck.ext4 -n /dev/sdb1

A clean second pass is meaningful confirmation the repair actually completed successfully, rather than assuming a single repair invocation that didn’t error out necessarily means the filesystem is now fully consistent — some corruption scenarios require more than one repair pass to fully resolve, and verifying with a fresh, non-modifying check is worth the extra few minutes before trusting the filesystem back into production use.

Why this whole sequence matters more than any individual command

The unmount-first, understand-the-corruption-second, repair-in-the-tool’s-intended-order-third sequence exists because filesystem repair tools are working with genuinely dangerous, all-or-nothing operations on structures that, if handled incorrectly, can turn recoverable corruption into unrecoverable data loss. Treating fsck/xfs_repair as “the one command that fixes filesystem problems” without respecting the order of operations they’re actually designed around is the most common way a filesystem repair situation gets meaningfully worse instead of better.