DragonFly commits List (threaded) for 2008-01
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
dillon 2008/01/24 21:49:09 PST
DragonFly src repository
sys/vfs/hammer hammer.h hammer_btree.c hammer_inode.c
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
* 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
* 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