DragonFly kernel List (threaded) for 2003-09
Re: cache_lookup() work this week.
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.
No, nowhere near. I'd rather adopt a filesystem like XFS then
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
like that can happen, first the VFS work really has to be completed. We
to move away from softupdates. A filesystem is nothing more than a
graph and with softupdates its not treated that way. This then breaks
to have an "upgrade" option in the installer were planning. Hence we
our DragonFly cd in a winblows machine and upgrade it to DragonFly.
a real upgrade would convert the windows filesystem to one that doesn't
itself to become fragmented and tries to avoid corruption(the default
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
unless the hardware has a CMOS data area that can be written with the
cause, even if it's a double panic (must distinguish power failure from
panic, as kernel panics result from corrupt kernel data, which means
check all files). Unless we can make one that journals on cylinder
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.....