Good progress continues to be made.  HAMMER survived acting as my
    LAN backup machine (in full historical mode) for almost a week before
    it hit an assertion.  I've fixed that issue and believe that the core
    filesystem implementation code is now 'very stable'.

    Note that the recent commit will result in many more 'hammer_lock_ex:'
    messages on the console then you may have previously observed.  This is
    due to the way object id's are allocated in the face of parallel 
    modifications to the filesystem, resulting in too much locality of
    reference in the B-Tree.  I do intend to improve it.

    I am still working on the two major items needed before HAMMER can be
    declared operational, those being the filesystem full handling and the
    undo/recovery-on-mount code.  These are the last 'hard' bits left in
    the design.

    With exception to filling up the filesystem, which *will* create a mess,
    and noting that no crash recovery code exists yet (so you have to newfs
    it if you crash), I'd appreciate it if interested parties could test
    the other functions of the filesystem, in particular the pruning and
    reblocking functions (man hammer), and the historical access functions.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>