HAMMER update 18-May-2008

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    I am going to put my foot down and will not be making any further
    changes to the on-media format.  Remaining performance issues are related
    to buffer clustering and frontend->backend double-buffering and can be
    handled without further changes to on-media structures.

    I am continuing to life-test HAMMER.  At the moment there is one major
    issue pending related to B_LOCKED not getting cleared on buffers,
    leading to a soft machine lockup.  I should have that fixed today.
    In fact, buffer management is working so well that literally the entire
    buffer cache needs to get into a B_LOCKED state before the machine
    actually locks up, so I expect things to be ultra-stable once I have
    fixed the issue.

    Crash recovery appears to be working very well, I have not lost a
    filesystem from either an intentional or accidental crash since the
    sync_lock was fixed a few days ago.  I am setting up a vkernel test
    w/ a kill -9 loop to really life-test the crash recovery code.

    --

    I intend to get the filesystem full handling working this week, after
    having spent last week on performance and stabilization issues. 

    The main programming issue here is that HAMMER's frontend cache is
    independant of the backend flusher.  It is possible to queue up a
    large amount of work in the form of creating files and directories,
    writing to files, removing files and directories, renames, chmods, and
    so forth.  There is not a single operation other then fsync() that
    actually requires writing to the actual media.

    When a HAMMER filesystem becomes full some of this cached information
    cannot be flushed.  My programming task for this week is to properly
    account for the space used by cached, dirty, unflushed information, to
    make sure sufficient space is available on the media to flush it.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>