HAMMER status 14-May-2008

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    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>