If a server loses power or crashes in the middle of writing to disk, a filesystem can be left half-updated: a file’s data written but its directory entry not, or blocks marked used that belong to nothing. Journaling prevents that kind of corruption by recording changes in a log before applying them.

How a journal works

  1. The filesystem writes a description of the change (a transaction) to the journal.
  2. It marks the transaction as committed.
  3. It applies the change to the main filesystem structures.
  4. It marks the transaction as complete.

After a crash, the filesystem replays committed transactions and discards incomplete ones. Recovery takes seconds instead of a full disk scan, and the filesystem’s structure stays consistent.

ext4 journaling modes

ext4, the default on Debian and Ubuntu, offers three modes (set with the data= mount option):

Mode What is journaled Trade-off
data=ordered (default) Metadata; data blocks are written before the metadata that points to them Good balance — no stale data appears in files after a crash
data=writeback Metadata only, data may be written in any order Slightly faster; files can contain old garbage after a crash
data=journal Metadata and data Safest, but every write happens twice — much slower for large writes

Leave the default unless you have a specific reason.

XFS

XFS (default on AlmaLinux and Rocky Linux) journals metadata and is designed for large files and parallel I/O. It can’t be shrunk, only grown. Repair uses xfs_repair instead of fsck.

Btrfs and ZFS: copy-on-write

Btrfs (and ZFS) don’t use a traditional journal. They never overwrite data in place: new data goes to free blocks, then pointers are switched atomically. This gives consistent state after crashes and enables snapshots and checksums of data — the filesystem can detect silent corruption. The trade-offs are more complexity and, for some database workloads, fragmentation.

What journaling does not protect

  • Data in application buffers that hasn’t been written yet. Applications that need durability (databases) call fsync().
  • Hardware failure. A dead disk takes the journal with it.
  • Accidental deletion or ransomware. The journal faithfully records rm -rf too.

Journaling keeps the filesystem consistent; backups keep your data safe. See Debian backup and disaster recovery.

Useful commands

# Filesystem types and mount options
findmnt -t ext4,xfs,btrfs

# ext4: journal and feature details
tune2fs -l /dev/vda1 | grep -iE 'features|journal'

# Check ext4 (must be unmounted — use a rescue system or check at boot)
fsck.ext4 -f /dev/vda1

# Force a check on next boot (root filesystem)
touch /forcefsck              # or add fsck.mode=force to the kernel command line

# XFS check (dry run) and repair (unmounted)
xfs_repair -n /dev/vdb1
xfs_repair /dev/vdb1

On a VPS, you can’t unmount the root filesystem while it’s running. Use the rescue mode or VNC console in your control panel, or schedule a check at boot.

Signs of filesystem trouble

  • Kernel messages like EXT4-fs error or I/O error in dmesg / journalctl -k.
  • The filesystem remounted read-only (touch /test fails with “Read-only file system”).
  • Files that suddenly read as zeros or can’t be opened.

If you see these, back up what you can immediately, then check the filesystem. Our guide to Linux kernel panics covers diagnosing crashes, and Linux disk caching explains how writes reach the disk.

  • Linux
  • Storage
  • Filesystems