HAMMER 60B/many: Stabilization
authorMatthew Dillon <dillon@dragonflybsd.org>
Thu, 3 Jul 2008 04:24:51 +0000 (04:24 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Thu, 3 Jul 2008 04:24:51 +0000 (04:24 +0000)
commita7e9bef1725d53a752fb4cd48c0106f88045346c
tree7c711340c4994206d7976c796b519d6ac46640d1
parent34ebae70b5f266ed243c4eebf688381e257d74ab
HAMMER 60B/many: Stabilization

* Redo the estimated space usage calculation, it was horribly broken.
  There may still be issues with read+write memory maps.

* Fix a bug in the reblocker that allowed it to exhaust all available
  space on the media.  While the reblocker eventually compacts the media
  it can actually require additional disk space while running.

Note that file deletions in normal history retention mode do not recover
any space unless followed by pruning, and may even require additional space.
If worse comes to worse a full filesystem might have to be remounted in
nohistory mode to recover space.

Reported-by: Gergo Szakal <bastyaelvtars@gmail.com>
sys/vfs/hammer/hammer.h
sys/vfs/hammer/hammer_blockmap.c
sys/vfs/hammer/hammer_inode.c
sys/vfs/hammer/hammer_reblock.c
sys/vfs/hammer/hammer_vfsops.c
sys/vfs/hammer/hammer_vnops.c