Re: Background fsck

["Xin LI" <delphij@xxxxxxxxxxxxx>]

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


>
> :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>
>
>