mirror of
https://github.com/kdave/btrfs-progs
synced 2025-04-27 21:47:56 +00:00
Since btrfs-image is just restoring tree blocks without really checking if that tree block contents makes sense, for multi-device image, block group items will keep the incorrect block group flags. For example, for a metadata RAID1 data RAID0 btrfs recovered to a single disk, its chunk tree will look like: item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 22020096) length 8388608 owner 2 stripe_len 65536 type SYSTEM item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 30408704) length 1073741824 owner 2 stripe_len 65536 type METADATA item 3 key (FIRST_CHUNK_TREE CHUNK_ITEM 1104150528) length 1073741824 owner 2 stripe_len 65536 type DATA All chunks have correct type (SINGLE). While its block group items will look like: item 1 key (22020096 BLOCK_GROUP_ITEM 8388608) block group used 16384 chunk_objectid 256 flags SYSTEM|RAID1 item 3 key (30408704 BLOCK_GROUP_ITEM 1073741824) block group used 114688 chunk_objectid 256 flags METADATA|RAID1 item 11 key (1104150528 BLOCK_GROUP_ITEM 1073741824) block group used 1572864 chunk_objectid 256 flags DATA|RAID0 All block group items still have the wrong profiles. And btrfs check (lowmem mode for better output) will report error for such image: ERROR: chunk[22020096 30408704) related block group item flags mismatch, wanted: 2, have: 18 ERROR: chunk[30408704 1104150528) related block group item flags mismatch, wanted: 4, have: 20 ERROR: chunk[1104150528 2177892352) related block group item flags mismatch, wanted: 1, have: 9 This patch will do an extra repair for block group items to fix the profile of them. Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> |
||
---|---|---|
.. | ||
main.c | ||
metadump.h | ||
sanitize.c | ||
sanitize.h |