DragonFly kernel List (threaded) for 2008-05
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
HAMMER status 14-May-2008
HAMMER's undo, reblocking, and pruning code now appear to be fairly
stable. I am continuing testing through this week, particularly
with regards to historical accesses. I made changes to generate a
fixed atime and mtime for historical accesses to make it possible
to validate a snapshot with a (tar ... | md5).
I fixed what I believe to be the last major UNDO bug today. Meta-data
buffers could wind up getting flushed at the wrong time, causing the
undo to blow up. I believe the UNDO is now 99% done (there are some
link count cases which still need to be tested but that's about it).
The UNDO code is what implements the recovery-on-mount feature.
Performance is significantly improved over a week ago. The B-Tree has
no problem handling tens of millions of records and I will be testing
into the hundreds of millions of records this week. (Note: My use of
the term 'record' refers to a B-Tree element).
Currently the pruning code does not deal with two non-critical cases.
The first case is if the system crashes while a program holds an
unlinked file open. Because the file was still open, but had no
filesystem visibility, its inode could wind up left on the media
with a link count of 0. The second case is related to B-Tree leafs
which cannot be immediately deleted due to hitting a non-fatal deadlock.
(in HAMMER deadlocks on B-Tree nodes are standard fair, they are detected
and retried). The pruning code will not clean up such nodes, yet.
The reblocking code isn't all that good as yet, but it does work. It
is possible to re-optimize the entire filesystem by specifying a
fill level of 100%. The hammer utility's -t and -c options work quite
well for incremental housekeeping.
I haven't coded handling for the filesystem full case yet, so don't
test that. That still remains the only functional module left to do.
I would appreciate testing of the crash recovery code, i.e. that the
filesystem does not get corrupted after a crash.
-Matt
Matthew Dillon
<dillon@backplane.com>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]