DragonFly kernel List (threaded) for 2004-01
Re: Background fsck
: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.
: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!).
: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
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
So, how can I (a) convince you that a filesystem journal is the way to
go and (b) maybe get you to write it ? :-) :-) (!)