After an unclean reboot an ext4 filesystem mounts in seconds, and a colleague insists that XFS 'has no fsck'. What actually happens at mount time on each of these filesystems, and how do you repair an XFS filesystem that refuses to mount?

## Two different operations that people conflate There are two distinct things that can happen to a filesystem after a crash, and the whole question turns on keeping them apart. **Log replay** happens automatically at mount. The filesystem finds its journal non-empty, applies the committed transactions recorded there, and is structurally consistent again. It is fast and its duration is bounded by the size of the log, not the size of the filesystem, which is exactly why a multi-terabyte volume can come back in seconds. **A repair pass** is a full traversal that validates every structure against every other one — do the allocation bitmaps agree with what the inodes claim, does every inode have a directory entry, is every directory entry pointing at a live inode. Its cost scales with the filesystem's contents, and it is only needed when something has gone wrong that the log cannot express: bad hardware, a firmware that lied about flushing its cache, a kernel bug, a volume snapshotted mid-write. After a normal unclean reboot you get the first. The second is an incident. ## What XFS actually does XFS replays its log at mount, and the tool for everything beyond that is `xfs_repair`, which requires the filesystem to be unmounted. The workflow: ``` xfs_repair -n /dev/sdb1 # report only, change nothing umount /srv/data # repair never runs on a mounted filesystem xfs_repair /dev/sdb1 ``` The confusing part — and the origin of "XFS has no fsck" — is `fsck.xfs`. It exists, it is installed, and its documented behaviour is to do nothing and exit with success. That is deliberate: boot-time machinery expects to be able to call `fsck.<type>` for any filesystem listed in fstab, and XFS's answer is "there is nothing useful to do here at boot; mount will replay the log, and if that fails an operator needs to make a decision." A candidate who says "XFS can't be checked" has misread a compatibility stub as an absence of tooling. There is one important ordering rule. `xfs_repair` refuses to work on a filesystem with a dirty log, because the log holds committed metadata it must not discard. The correct move is to mount the filesystem once so the kernel replays the log, unmount it, and then repair. Only if the log itself is damaged and cannot be replayed do you reach for `xfs_repair -L`, which zeroes the log — throwing away every transaction it held. That means real, unrecoverable metadata loss, potentially files or whole directories. It is the option you use when the alternative is restoring from backup anyway, and you note in the incident record that you used it. ## What ext4 does ext4 replays its jbd2 journal at mount in the same way. Its repair tool is `e2fsck`, and the same rule applies: never on a mounted read-write filesystem, because the on-disk state is changing underneath it. ``` e2fsck -n /dev/sdb1 # report only e2fsck -f /dev/sdb1 # force a full check even if the fs looks clean ``` The `-f` matters because `e2fsck` skips the full pass when the superblock says the filesystem is clean, which after a successful journal replay it does. If you actually want the exhaustive traversal — because you suspect the hardware, not the shutdown — you have to ask for it. ext4 also carries the legacy of periodic checking: the maximum mount count and check interval, viewable and adjustable with `tune2fs -l`, `-c` and `-i`, would force a check at boot after so many mounts or so many days. Most distributions disable these now, because an unexpected multi-hour check at boot is worse than the risk it hedges. When `e2fsck` cannot read the primary superblock, ext4's backup superblocks are the recovery path; `mke2fs -n` reports where they are on an existing filesystem without writing anything. ## What neither of them does Neither tool validates your file contents. XFS's v5 on-disk format checksums its *metadata*, so corruption in the filesystem's own structures is detected rather than silently propagated, and ext4 has metadata checksums too — but file data is unchecked on both. A block that flipped a bit under your database's table will be handed back to the application exactly as stored, and no repair pass will notice. That is precisely the guarantee copy-on-write filesystems with data checksums are selling, and it is worth saying so, because it frames what a repair tool is and is not for. It also means a successful `xfs_repair` is not a statement that your data is fine. It is a statement that the filesystem's structure is now self-consistent — which sometimes it achieves by moving orphaned inodes into `lost+found` and letting you work out what they were. ## How to answer Lead with the replay-versus-repair distinction, because that is the actual content of the question. Then explain `fsck.xfs` as the compatibility stub it is, name `xfs_repair` and `e2fsck` as the real tools, insist on unmounted in both cases, and flag `-n` first and `-L` last. Finishing with "and neither of them checks my file data" is what makes the answer sound like it came from someone who has done it at three in the morning.