devutils/ATFQ/book ATFQ git

Part I · How it works

9.2 Journaling: how a filesystem survives a crash

alsojournalingjournaled filesystemjournal modedata=orderedfscke2fsckfilesystem corruptionread-only file systemremount-roxfs_repair

TL;DR

  • Creating a file touches several places on disk: the inode, the folder, the free-space map. A crash in between would leave them disagreeing.
  • A journal writes the whole change to a log area first, then applies it. After a crash, the filesystem replays or drops the logged changes: consistent again in seconds, without a full check.
  • ext4 and XFS journal metadata; your file's content still needs fsync (4.5).
findmnt -no OPTIONS /        # mount options of the root filesystem
sudo dmesg | grep -iE 'ext4|xfs|btrfs'   # errors and journal replays

On your machine

alice@laptopexample
$ atfq 9.2
  /         btrfs on /dev/nvme0n1p2 · SSD mode
  /home     btrfs on /dev/nvme0n1p2 · SSD mode
  /var/lib/my data btrfs on /dev/nvme0n1p2 · SSD mode
  /boot/efi vfat on /dev/nvme0n1p1
  /media/usb exfat on /dev/sda
  /home     btrfs on /dev/nvme0n1p2

An example: Alice's laptop, one of the test machines. In your terminal, this block shows your own machine, read live.

Pitfalls

Deep dive 2 questions

What does ext4's default mode, data=ordered, promise?

Metadata goes through the journal; file data isn't journaled, but it's written before the metadata that points to it is committed. So after a crash, a file may hold its old content or its new content, never blocks of someone else's deleted data. data=journal also journals the data: safer, and much slower.

Why does a journal make the check fast?

Without one, the only way to know the filesystem is consistent after a crash is to read every inode and folder: minutes to hours on a large disk. With a journal, only the last few seconds of changes can be unfinished, and they're all in one small area.

Commands
fsck dmesg mount
Paths
/etc/fstab
See also
14. Disk
9.1 How a filesystem stores a file
4.5 fsync: when is data really on disk?
21.3 dmesg and the kernel log