cvs commit: src/sys/vfs/hammer hammer.h hammer_btree.c hammer_inode.c hammer_io.c hammer_object.c hammer_ondisk.c hammer_recover.c hammer_spike.c hammer_vfsops.c hammer_vnops.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>]

dillon      2008/01/24 21:49:09 PST

DragonFly src repository

  Modified files:
    sys/vfs/hammer       hammer.h hammer_btree.c hammer_inode.c 
                         hammer_io.c hammer_object.c 
                         hammer_ondisk.c hammer_recover.c 
                         hammer_spike.c hammer_vfsops.c 
                         hammer_vnops.c 
  Log:
  HAMMER 24/many: Clean up edge cases
  
  Hammer now survives many cpdup/rm-rf loops with recovery forced on.
  
  * Fix an edge case with historical lookups.  When pushing down through a
    spike an exact match on a SPIKE_END element is no guarantee of success,
    so check for and flag the delete boundary in that case.
  
  * Delay physical cluster deletions (marking the cluster as free in the
    Volume's A-list) until the last ref on the cluster goes away.
  
  * Fix a race between cluster deletion, filesystem sync, and recovery.
    Do not attempt to recover a cluster marked as undergoing deletion.
  
  * Enable cluster recovery by default.  It is still fairly primitive but
    it should work well enough to put the filesystem in a working state
    once the remaining debug shims are removed.
  
  * Clean up sequencing of io->modified to ensure that clusters are properly
    closed during normal operation.  Recovery operations should only occur
    when encountering an open cluster after a crash.
  
  * Do not open a cluster or create a cluster->buffer dependancy when only
    updating the mtime or atime of an inode.
  
  * In the hammer_sync_*() procedures, ref the volume/cluster prior to
    scanning its RB tree, use hammer_ref() instead of hammer_ref_*() to
    avoid unnecessary loads.  This also fixes a stale pointer bug in the
    same code.
  
  * Remove the stack recursion in btree_remove().  btree_remove() is now able
    to clean up empty nodes going all the way up the tree (at least until it
    hits a deadlock, which is not yet handled).
  
  * Fix primary filesystem statistics (they were getting off because
    whole clusters were being deleted without bothering to free up internal
    on-disk structures).
  
  * Fix a minor bug in the cluster's stat_records tracking field.  'df' no
    longer shows a bleeding capacity.  Statistics will still get off due
    to crashes and such (the balancer will probably have to deal with that).
  
  * Add more assertions.  How do you debug complex code?  You assert that
    everything is in its proper state, everywhere you can.
  
  Revision  Changes    Path
  1.29      +7 -0      src/sys/vfs/hammer/hammer.h
  1.24      +73 -34    src/sys/vfs/hammer/hammer_btree.c
  1.25      +1 -1      src/sys/vfs/hammer/hammer_inode.c
  1.18      +75 -58    src/sys/vfs/hammer/hammer_io.c
  1.24      +16 -5     src/sys/vfs/hammer/hammer_object.c
  1.25      +75 -16    src/sys/vfs/hammer/hammer_ondisk.c
  1.7       +5 -3      src/sys/vfs/hammer/hammer_recover.c
  1.12      +6 -3      src/sys/vfs/hammer/hammer_spike.c
  1.15      +5 -1      src/sys/vfs/hammer/hammer_vfsops.c
  1.23      +6 -1      src/sys/vfs/hammer/hammer_vnops.c


http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer.h.diff?r1=1.28&r2=1.29&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_btree.c.diff?r1=1.23&r2=1.24&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_inode.c.diff?r1=1.24&r2=1.25&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_io.c.diff?r1=1.17&r2=1.18&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_object.c.diff?r1=1.23&r2=1.24&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_ondisk.c.diff?r1=1.24&r2=1.25&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_recover.c.diff?r1=1.6&r2=1.7&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_spike.c.diff?r1=1.11&r2=1.12&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_vfsops.c.diff?r1=1.14&r2=1.15&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_vnops.c.diff?r1=1.22&r2=1.23&f=u