Re: Background fsck

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi all,
:this is the outline of how to implement a background fsck for DragonFly.
:DR, this is somewhat more mature than what I wrote on Friday.
:
:Joerg

: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 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!).

:Proposal
:--------
:
:First of all, the "clean" requirement for a read-write mount of a softdep fs
:should be droped. This is what FreeBSD 5 already does.
:
:Second add the functionality to free a block, fragment or inode by number
:or adjust the reference count of an inode.
:
:Third instrument certain FFS functions to notify the userland fsck of
:updates to the filesystem structure. This is further detailed in the next
:section.

    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.

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

: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 ?  :-) :-) (!)

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>