Is fsck obsolet for journaling FS? - Was: How do I Automount [snip]

Robert Heller heller at
Sun Nov 29 20:03:34 UTC 2015

At Sun, 29 Nov 2015 19:30:34 +0100 "Ubuntu user technical support,  not for general discussions" <ubuntu-users at> wrote:

> Hi,
> On Sun, 29 Nov 2015 18:02:26 +0100, Oliver Grawert wrote:
> >> It still would be interesting to learn how fsck, recommended by the
> >> Ubuntu fstab help, is managed when using gnome-disks. Since I didn't
> >> see a screenshot that shows fsck settings, I suspect it automatically
> >> writes the value 2 to fstab, or how is it handled?  
> >dunno, try it out but effectively that field is legacy nonsense anyway.
> >unless you use ext2 or minix disks without journalling ...
> I will not edit the Ubuntu help pages. I would have the time to do so
> at the moment, but in this case not the knowledge.
> Assumed journaling file systems don't require periodically fsck, than it
> shouldn't be per se recommended by Ubuntu help pages (and Wikis of
> other distros).

Actually, journaling file systems *do* require periodically fsck.  They just 
don't need to run fsck everytime there is a 'crash' reboot (i.e. someone yanks 
the power cord or presses the reset button or something like that).  Actually 
fsck is the program that handles journal processing when mounting an 'unclean' 
journaled file system, so yes fsck really is still used.

> Why does an Ubuntu default install sets the value for ext4 file systems
> to 1 for the root directory and to 2 for other ext4 directories?

The numbers refer to which file systems can't be fsck'ed in 'parallel' or at
least in the same 'round' of fsck's. 1 for the root (done very early in the
boot processes), 2 for other FS's on the main physical disk ([logical]
spindle), 3 for other spindles, etc. The idea here is you don't want two (or
more) parallel processes doing seeks on the same spindle at the same time.
This either greatly slows things down or causes excessing wear and tear on the
drives, etc.  All of the file systems with a given number are done 
sequencentially by a single process.  On a typical (eg desktop system with one 
logical 'disk'), the root FS gets a level of fsck'ing while still in initramfs 
mode), then the other FS's in fstab are done when the mount -all step is done 
from the init (or whatever) process.  If the machine had multiple logical 
disks (either multiple physical disks or multiple RAID arrays), the disks with 
2 would be fscked in *parallel* with the disks with 3 and 4 and 5, since these 
would be different spindles and disk seeks would not interfere with each 
other.  With modern computers it is pretty rare to have more than one or two 
spindles / logical disks.  And for many desktop installs, it is rare to even 
have more than one file system.

> The only evidence I found on the quick, that fsck is obsolet for at
> least one purpose is:
>   "A journaling file system is designed such that tools such as fsck do
>   not need to be run after unclean shutdown (i.e. crash)." -

This is not *strickly* accurate.  It is true in the sense that a detailed scan 
of the system data blocks, free blocks and inodes is not needed, but it is 
needful to 'recover the journal'.  In theory, one would have a separate 
program (not fsck) that would handle the journal recovery.  In practice, e2fsk 
does the journal recovery if the FS is ext3 or ext4.  And then...

>   "File system can become inconsistent due to several reasons and the
>   most common is abnormal shutdown due to hardware failure , power
>   failure or switching off the system without proper shutdown. Due to
>   these reasons the superblock in a file system is not updated and has
>   mismatched information relating to system data blocks, free blocks and
>   inodes ." -

.. might go on to do a regular fsck because a fsck has not happened in the
time frame allowed for (tune2fs -i ...) or because the system has been
mounted/unmounted more than a certain number of times (tune2fs -c ...). This
latter fsck is not so much to fix a known problem (unclean filesystem) but to
look and see if something broken happened during normal operations (a sort of
'just in case' check). *I* have never had a problem show up with an otherwise
healthy disk. For some low value file systems I disable the periodic fsck's
(tune2fs -c 0 -i 0 /dev/<disk>), in order to avoid the 'waste of time' of a

> OTOH what e.g. is fsck.ext4 for?
>   "2. Fsck Command Specific to a Filesystem Type
>   fsck internally uses the respective filesystem checker command for a
>   filesystem check operation. These fsck checker commands are typically
>   located under /sbin.
>   The following example show the various possible fsck checker commands
>   (for example: fsck.ext2, fsck.ext3, fsck.ext4, etc.)" -

On a typical Linux system fsck.ext2, fsck.ext3, and fsck.ext4 are (sym)links
to e2fsck: dir -li /sbin/fsck.* /sbin/e2fsck
142163 -rwxr-xr-x. 5 root root 197352 Jul 24 06:33 /sbin/e2fsck*
142094 -rwxr-xr-x. 1 root root  15976 Oct 15  2014 /sbin/fsck.cramfs*
142163 -rwxr-xr-x. 5 root root 197352 Jul 24 06:33 /sbin/fsck.ext2*
142163 -rwxr-xr-x. 5 root root 197352 Jul 24 06:33 /sbin/fsck.ext3*
142163 -rwxr-xr-x. 5 root root 197352 Jul 24 06:33 /sbin/fsck.ext4*
142163 -rwxr-xr-x. 5 root root 197352 Jul 24 06:33 /sbin/fsck.ext4dev*
147846 lrwxrwxrwx. 1 root root      7 May 12  2015 /sbin/fsck.msdos -> dosfsck*
147847 lrwxrwxrwx. 1 root root      7 May 12  2015 /sbin/fsck.vfat -> dosfsck*

> Regards,
> Ralf
> PS:
> Regarding the original thread: No, I don't install gnome-disk-utility,
> since it has got a much to long dependency chain for installing it,
> just for taking a look at it.

Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services  -- Linux Administration Services
heller at       -- Webhosting Services

More information about the ubuntu-users mailing list