Re: Background fsck

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Mon, Jan 19, 2004 at 08:45:30AM -0800, Matthew Dillon wrote:
> :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.
> 
>     This actually doesn't slow down meta-data updates all that much,
>     because the journal is linear it takes only one seek to update while
>     you might need hundreds of seeks to update the meta-data in its 
>     individual locations on the disk.
> 
>     This is really the best way to do it, I think.

The journal should at least be spread over the disk. E.g. the seek
argument is somewhat weak since you need (a) to write the meta-data
to disk anyway and seek for that and (b) to seek for the normal read
activity. 

> 
> 
> :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.
> :..
> :
> :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.
>  
>     I don't want to touch softupdates, other then to fix bugs.  It's too
>     complex (without Kirk anyway!).

You are not alone. I don't want to touch softupdates, since almost all
functionality is already in place ready to use. The only reason I mentioned
softupdates is they are needed in any case for stuff like this.

[snip]
>     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.

IMO the whole concept of clean and dirty is somewhat rusted with softdeps
used for most filesystems. This would reduce the work and could be
done in parallel to the softdep code, but like you said -- not without Kirk!

>     I really dislike the concept of a background fsck.  I don't trust it.

That's the problematic part. For the background fsck there is one
assumption which must hold true. At one time or another the fsck
must find any ressource. That's what complicates the process a bit.
Doing it in kernel would simplify things a bit, but the basic problem
is the same. But anyway could you live with allowing the R/W mount
of dirty softdep fs? You can run the fsck later, it is only needed to
recollect some unreferenced inodes and blocks.

> :This schema has the advantage of needed no additional I/O beside
> :reading the complete filesystem tree. The additional messages should
> :provide a small overhead, but not larger than having a snapshot in
> :place.
> :
> :Joerg
> 
>     So, how can I (a) convince you that a filesystem journal is the way to
>     go and (b) maybe get you to write it ?  :-) :-) (!)

I will dig into David's journal code anyway, since this is at least
interesting. I haven't changed my PoV concerning Journal vs. Softdep yet,
but we should get some real performance numbers once we have both
Journaling and Softdeps in tree.

Joerg

> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>