mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
synced 2024-11-28 14:44:36 +08:00
e916d57466
[BUG] If restoring dumped image to a new file, under most cases kernel will reject it since version 5.11: # mkfs.btrfs -f /dev/test/test # btrfs-image /dev/test/test /tmp/dump # btrfs-image -r /tmp/dump ~/test.img # mount ~/test.img /mnt/btrfs mount: /mnt/btrfs: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error. # dmesg -t | tail -n 7 loop0: detected capacity change from 10592 to 0 BTRFS info (device loop0): disk space caching is enabled BTRFS info (device loop0): has skinny extents BTRFS info (device loop0): flagging fs with big metadata feature BTRFS error (device loop0): device total_bytes should be at most 5423104 but found 10737418240 BTRFS error (device loop0): failed to read chunk tree: -22 BTRFS error (device loop0): open_ctree failed [CAUSE] When btrfs-image restores an image into a file, and the source image contains only single device, then we don't need to modify the chunk/device tree, as we can reuse the existing chunk/dev tree without any problem. This also means, for such restore, we also won't do any target file enlarge. This behavior itself is fine, as at that time, kernel won't check if the device is smaller than the device size recorded in device tree. But later kernel commit 3a160a933111 ("btrfs: drop never met disk total bytes check in verify_one_dev_extent") introduces new check on device size at mount time, rejecting any loop file which is smaller than the original device size. [FIX] Do extra file enlarge for single device restore if the restored file is smaller than the device size. Reported-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Su Yue <l@damenly.su> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> |
||
---|---|---|
.. | ||
main.c | ||
Makefile | ||
metadump.h | ||
sanitize.c | ||
sanitize.h |