Background fsck

[Xin LI]

----- Original Message ----- 
From: "Matthew Dillon" <dillon at xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, January 20, 2004 12:45 AM
Subject: Re: Background fsck


>     I kinda prefer the journal idea.  As an alternative iet would be
possible
>     to augment the filesystem code to mark individual cylinder groups and
>     dirty or clean to greatly reduce the amount of work that fsck had to
do,
>     but that would take considerable work inside fsck and a moderate
amount
>     of work in the filesystem code.
Well Matt, I have a little bit suspect the journal idea.

While it is possible to keep metadata consistency, it's *required* to write
the journal data synchronously, which will decrease performance. Without
doing the journal writes synchronously we are under the risk of losing
important metadata updates, and even lost the chance to bring the filesystem
into a consistency state.

By marking individual cylinder groups dirty or clean, we will have to
initialize more write operations, which will also slow down the filesystem
operation. It's questionable how these code will be more simple compared to
soft updates and we have to maintain it alone (not to share the fixes
available in FreeBSD). What's more, by having a journal we will face to
increased abrasion (because journals must be stored in some places which
location are fixed and the write of journals are usually rolling) on certain
parts of disks and in my opinion that are unnecessary when there's soft
updates available.

Finally, using of journalling requires modification to the metadata format,
which will lead to some problem when users upgrade their system, so a
converter might be necessary of DFly finally chooses this approach.

>     I really dislike the concept of a background fsck.  I don't trust it.
For a successful background fsck to be finished, we must at least guarantee
soft updates rules to be enforced, and this, for either FreeBSD-CURRENT,
FreeBSD-STABLE and DragonFly, were violated in several ways. For instance,
to improve performance, hw.ata.wc was enabled by default and because IDE
Hard disks will "cheat" the operating system about the write results,
softdep code may hence write some incorrect data to disk (because it
"intelligently" re-order some writes which is not wanted by the OS).

A second reason why background fsck is questionable might because the
snapshot code is still in its alpha-quality stage and is not mature enough.

Considering that the snapshots are usually ephemeral (because they are
usually used to backup or have a background fsck), I think it might be
possible to implement the whole SoftUpdates policies in the VFS layer, as
David Rhodes pointed out in a recent post. Unfortunately, this apparently
will drastically increase the complexity of VFS code and it is questionable
whether this is worthy to have a try.

The only thing I am worrying about background fsck is, while we can mount a
dirty filesystem and run fsck in the background, it may turn out that an
incorrect reference number on an i-node may cause it impossible to remove it
before the bgfsck is finally done... This will sometimes cause application
to crash...