git: HAMMER VFS - Fix probable corruption case when filesystem b
commit 07ed04b554263ecb5e36bf8ce5f9cd7e99614e1a
Author: Matthew Dillon <dillon@apollo.backplane.com>
Date: Sun Apr 18 22:36:14 2010 -0700
HAMMER VFS - Fix probable corruption case when filesystem becomes nearly full
* The reblocking code was incorrectly assuming the cursor would be pointing
at a valid node element after an unlock/relock sequence, when it could
actually be pointing at the EOF of a node. This case can occur when
the filesystem is nearly full (possibly due to the reblocking operation
itself), when the filesystem is also under load from unrelated
operations.
* This can result in the creation of a corrupted B-Tree leaf node or
data record.
* Corruption can be checked with hammer checkmap and hammer show
(as of this rev):
hammer -f device checkmap
Should output no B-Tree node records or free space mismatches.
You will still get the initial volume summary.
hammer -f device show | egrep '^B' | egrep -v '^BM'
Should output no records.
* Currently the only recourse if corruption is found is to copy off the
filesystem, newfs_hammer, and copy it back.
Full history and snapshots can be retained by using 'hammer -B mirror-read'
to copy off the filesystem and mirror-write to copy it back. However,
pleaes remember you must do this for each PFS individually. Make sure
you have a viable backup before newfsing anything.
Reported-by: Francois Tigeot <ftigeot@wolfpond.org>, Jan Lentfer <Jan.Lentfer@web.de>
Summary of changes:
sys/vfs/hammer/hammer_reblock.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/07ed04b554263ecb5e36bf8ce5f9cd7e99614e1a
--
DragonFly BSD source repository