Background fsck vs. journaling

Joerg Sonnenberger wrote up a proposal for background fsck, which he posted to the kernel discussion group. I”m pasting it wholesale.

(Matt Dillon has indicated he would prefer a journaling filesystem.)


Background
———-

ATM DragonFly forces a full fsck for before allowing a non-forced read-write
mount of a unclean filesystem. Since this filesystem checks can take quite
a long time, alternatives are highly desired.

The first alternative is using a journal for all meta-data updates. That’s
what most Linux filesystems are doing. The advantage is almost no time
needed to bring a uncleanly unmounted filesystem back into a working state.
The disadvantage is a steady slow down for all meta-data updates.

The second alternative is provided by FreeBSD 5. It uses the soft updates
code to provide a consistent filesystem even in case of power failure etc.
Therefore you can mount a filesystem with soft updates instantly. Without
further processing the only disadvantage is some missing space. In detail
does the softdep code guaranty that the only incorrections on the fs are
free blocks and inodes still marked as in use. To garbage collect those
ressources FreeBSD 5 uses the filesystem snapshot mechanism to provide
a consistent and stable view of the filesystem for fsck. This allows the
filesystem to be used without any performance penalty as soon as the
background fsck has completed.

While the snapshot code is useful for other things as well, e.g. backups,
it is IMO far to general for this special application. Esp. since snapshots
are persistent across reboots and therefore disk backed they can result
in quite some unnecessary I/O load.

Proposal

4 Replies to “Background fsck vs. journaling”

  1. I have to agree with Matt about prefer to have a journaling filesystem. The background fsck is a little improvement only for UFS/SoftUpdate, but not always work great. I have managed lost over 3,000 emails like three or four times by Nvidia driver crash that the background fsck has never able to recovery them back.

  2. In the long run, it would be nice to have support for both UFS + softupdates as well as a journaling filesystem. I don’t really know the technical differences between journaling and softupdates all that well, but softupdates seems to be a very interesting system with good performance.

    Can dragonfly mount a UFS/UFS2 filesystem that has softupdates in non-softupdates mode right now?

  3. I hope they do journaling filesystem. Correct me if I am wrong I thought Matt wanted to port XFS from linux to Dragonfly that would be good. Couldn’t we have a choice after the first release to have a boot option between softupdates and journaling?

  4. “Correct me if I am wrong I thought Matt wanted to port XFS from linux to Dragonfly that would be good”

    Well, as long as the GPL doesn’t get all tangled up in the kernel, it’s okay. If he decides to merely use Linux’s as an example and basically writes his own XFS implementation from scratch, then that would be a very reasonable thing to do.

Comments are closed.