DragonFly BSD
DragonFly kernel List (threaded) for 2003-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cache_lookup() work this week.


From: David Rhodus <drhodus@xxxxxxxxx>
Date: Fri, 5 Sep 2003 18:29:13 -0400


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





[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]