Darrick J. Wong 09282b8a0b 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>		2015-01-28 08:53:54 -05:00
..
expect.1	e2fsck: decrement bad count _after_ remapping a duplicate block	2015-01-28 08:53:54 -05:00
expect.2	e2fsck: decrement bad count _after_ remapping a duplicate block	2015-01-28 08:53:54 -05:00
image.gz	e2fsck: decrement bad count _after_ remapping a duplicate block	2015-01-28 08:53:54 -05:00
name	e2fsck: decrement bad count _after_ remapping a duplicate block	2015-01-28 08:53:54 -05:00