Whamcloud - gitweb
e2fsck: decrement bad count _after_ remapping a duplicate block
authorDarrick J. Wong <darrick.wong@oracle.com>
Wed, 28 Jan 2015 13:53:54 +0000 (08:53 -0500)
committerTheodore Ts'o <tytso@mit.edu>
Wed, 28 Jan 2015 13:53:54 +0000 (08:53 -0500)
commit09282b8a0b4b8ff7c57daf371dc3ea192e2947d3
treedc661efe03fa1f0acedefd823b7fd8872db27efb
parent5e61441a4026d410fb8466eb93cf0375e32836d3
e2fsck: decrement bad count _after_ remapping a duplicate block

Decrement the bad count *after* we've shown that (a) we can allocate a
replacement block and (b) remap the file block.  Unfortunately,
the only way to tell if the remapping succeeded is to wait until the
next clone_file_block() call or block_iterate3() returns.

Otherwise, there's a corruption error: we decrease the badcount once in
preparation to remap, then the remap fails (either we can't find a
replacement block or we have to split the extent tree and can't find a
new extent block), so we delete the file, which decreases the badcount
on the block a second time.  Later on e2fsck will think that it's
straightened out all the duplicate blocks, which isn't true.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
e2fsck/pass1b.c
tests/f_cloneblock_alloc_error/expect.1 [new file with mode: 0644]
tests/f_cloneblock_alloc_error/expect.2 [new file with mode: 0644]
tests/f_cloneblock_alloc_error/image.gz [new file with mode: 0644]
tests/f_cloneblock_alloc_error/name [new file with mode: 0644]