cache_lookup() work this week.

[David Rhodus]

On Friday, September 5, 2003, at 05:29 PM, Matthew Dillon wrote:

:Are we at some point going to incorporate background fsck.  If so we 
could make fsck
:work like a garbage collector and do some sort of mark and sweep 
check for cycles.
:
:-billy

    No, nowhere near.  I'd rather adopt a filesystem like XFS then 
waste
    time on a background fsck.  Way in the future.
Not too far away....

BG fsck can be made to work in a week. It's a close to around 1000 lines
of kernel code you have to change to make it work. Though before a 
change
like that can happen, first the VFS work really has to be completed. We 
need
to move away from softupdates. A filesystem is nothing more than a 
dependency
graph and with softupdates its not treated that way. This then breaks 
the ability
to have an "upgrade" option in the installer were planning. Hence we 
can't place
our DragonFly cd in a winblows machine and upgrade it to DragonFly. 
Because
a real upgrade would convert the windows filesystem to one that doesn't 
allow
itself to become fragmented and tries to avoid corruption(the default 
DragonFly
filesystem here).

I am on the same idea that implementing BG fsck would be moot. I'd
rather see work done on starting to address the real problem not adding
some hacks on top of it. What should be done is work on a Journalling or
Log-structured FS. Even though that will not save us in some failure 
cases,
unless the hardware has a CMOS data area that can be written with the 
failure
cause, even if it's a double panic (must distinguish power failure from 
kernel
panic, as kernel panics result from corrupt kernel data, which means 
you must
check all files). Unless we can make one that journals on cylinder 
groups, though
no one has done a implementation to do this yet.

One thing holding people back in that is the issue with manufacturers 
who do not
provide track boundary information. Because without it you don't know 
if a track
boundary doesn't span a corruption boundary.....

-DR