5

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!

  • fsck of root also takes place already in initrd/ initramfs, where the journal gets replayed non-verbously, and thus the main system's fsck reports 'clean'. I was just not really used to that since I am usually using my own configured kernel and don't need an initrd/ initramfs. – Golar Ramblar Apr 2 '17 at 13:07
6

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.

  • Thanks. Before I used ext4, I was using ext3, and there was always a "full fsck" after an unclean unmount. – Golar Ramblar Sep 17 '15 at 9:17
3

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/

  • But for the other, non-ext4-filesystems, also the message "... was not cleanly unmounted, check forced" appears, and then fsck runs, and only during the run it recognises if everything is clean or not (usually, on /var, which is reiserfs, it replays journal entries; on /boot, which is ext2, it runs, displays progress bar, and reports "clean" after running). Only on the root filesystem no "check forced" and no fsck-progress appears. That is the worrying difference! – Golar Ramblar Sep 16 '15 at 20:32
  • Maybe it is deactivated in your fstab (/etc/fstab), check the 6th column, it correspond to fsck option, 0 means "do not check" – herbert Sep 16 '15 at 20:46
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.