ext4 reported as clean by fsck after hard reset: Is that normal?

Question

My root-partition is formatted as ext4-filesystem.

I notice that, whenever my machine crashes and I have to hard-reset it, when booting up again and the root filesystem is checked this step takes a bit (like one to two seconds) longer than when booting from a cleanly shut down system, but it is reported as "clean" (and nothing like /dev/<rootpartition> was not cleanly unmounted, check forced). The filesystem is 92% full (352 GiB).

My question: I wonder if this is the normal and a safe behaviour of ext4 or some bug in the startup-scripts. I know that ext4 has much faster fsck than ext3, but I am worried about that it is reported as "clean" after a system crash.

When I run e2fsck -f manually on that partition the check lasts comparable to an ext2/ext3 filesystem. So I am worried and since beeing so i tuned my filesystem to be checked at every boot (tune2fs -c 1), which results in a full check taking as long as e2fsck -f every boot.

Edit, just to clarify: After a non-clean reset, usually, on /var, which is reiserfs, fsck replays journal entries; on /boot, which is ext2, fsck runs, displays progress bar, and reports "clean" after running. Only on the root filesystem no "check forced" and no fsck-progress appears, which do appear for the other file systems even if they turn out to be clean. That is the worrying difference!

Answer 1

ext4 is a journaling filesystem, the and one of the main goals of journaling is to survive unclean shutdowns w/o damage, and thus not require a long fsck.

In short, a journaling filesystem like ext3/4 writes metadata (at least) changes twice. First, it writes them to the "journal". Then, once that's on disk, it writes to the actual filesystem metadata. (Writing to the journal is much faster, as the journal is sequential and doesn't require a bunch of seeks. At least on magnetic disks—seek penalty is greatly reduced on SSDs.)

The several extra seconds is likely the journal replay: basically, if the filesystem isn't unmounted cleanly, the next mount or fsck will read the journal and apply any changes that aren't yet in the main filesystem.

So, in short, sounds like its behaving as expected.

Answer 2

Fsck is usually run at startup when your filesystem was not unmounted cleanly (typically when you have to hard-reset). fsck will check your filesystem before mounting it and reports error if it detect that something goes wrong (inconsistencies, fail to replay the journal, orphan inodes...) or it will report "clean" if it do not detect any errors. So in your case you get lucky and your filesystem is ok. There is a very interesting post about fsck if you would like some more information of how it works internally: https://lwn.net/Articles/248180/

Answer 3

The fsck already takes place within the initrd/ initramfs (after an unclean shutdown it takes several seconds longer with a lot of disk activity at this stage, where the journal seems to be replayed), and thus, when the normal, more verbose, file system checks are beeing run from the main system, it is already clean.