mirror of
https://github.com/kdave/btrfs-progs
synced 2024-12-26 08:02:21 +00:00
btrfs-progs: corrupt-block: re-generate the checksum for generation corruption
[BUG] If using btrfs-corrupt-block to corrupt the generation of a tree block (in my example, it's csum root), it will cause csum mismatch other than the expected transid mismatch: # ./btrfs-corrupt-block --metadata-block 30474240 -f generation \ /dev/test/scratch1 # btrfs check /dev/test/scratch1 Opening filesystem to check... checksum verify failed on 30474240 wanted 0xb3e8059a found 0xb4a4b45c checksum verify failed on 30474240 wanted 0xb3e8059a found 0xb4a4b45c checksum verify failed on 30474240 wanted 0xb3e8059a found 0xb4a4b45c Csum didn't match ERROR: could not setup csum tree ERROR: cannot open file system [CAUSE] Inside the switch branch BTRFS_METADATA_BLOCK_GENERATION in corrupt_metadata_block(), we just set the generation and trigger write_and_map_eb(). However write_and_map_eb() doesn't re-generate the checksum by itself, thus we make the victim tree block to have a stale checksum. [FIX] Just call csum_tree_block_size() before write_and_map_eb(). Now the corrupted fs have the expected corruption pattern now: # btrfs check /dev/test/scratch1 Opening filesystem to check... parent transid verify failed on 30474240 wanted 7 found 11814770867473404344 parent transid verify failed on 30474240 wanted 7 found 11814770867473404344 parent transid verify failed on 30474240 wanted 7 found 11814770867473404344 Ignoring transid failure ... Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
This commit is contained in:
parent
d8f3355734
commit
d476b5bc0c
@ -885,6 +885,8 @@ static int corrupt_metadata_block(struct btrfs_fs_info *fs_info, u64 block,
|
||||
u64 bogus = generate_u64(orig);
|
||||
|
||||
btrfs_set_header_generation(eb, bogus);
|
||||
csum_tree_block_size(eb, fs_info->csum_size, 0,
|
||||
fs_info->csum_type);
|
||||
ret = write_and_map_eb(fs_info, eb);
|
||||
free_extent_buffer(eb);
|
||||
if (ret < 0) {
|
||||
|
Loading…
Reference in New Issue
Block a user