On Wed, Jun 24, 2020 at 07:55:26PM +0800, Qu Wenruo wrote: > [BUG] > The following script could lead to corrupted btrfs fs after > btrfs-convert: > > fallocate -l 1G test.img > mkfs.ext4 test.img > mount test.img $mnt > fallocate -l 200m $mnt/file1 > fallocate -l 200m $mnt/file2 > fallocate -l 200m $mnt/file3 > fallocate -l 200m $mnt/file4 > fallocate -l 205m $mnt/file1 > fallocate -l 205m $mnt/file2 > fallocate -l 205m $mnt/file3 > fallocate -l 205m $mnt/file4 > umount $mnt > btrfs-convert test.img > > The result btrfs will have a device extent beyond its boundary: > pening filesystem to check... > Checking filesystem on test.img > UUID: bbcd7399-fd5b-41a7-81ae-d48bc6935e43 > [1/7] checking root items > [2/7] checking extents > ERROR: dev extent devid 1 physical offset 993198080 len 85786624 is beyond device boundary 1073741824 > ERROR: errors found in extent allocation tree or chunk allocation > [3/7] checking free space cache > [4/7] checking fs roots > [5/7] checking only csums items (without verifying data) > [6/7] checking root refs > [7/7] checking quota groups skipped (not enabled on this FS) > found 913960960 bytes used, error(s) found > total csum bytes: 891500 > total tree bytes: 1064960 > total fs tree bytes: 49152 > total extent tree bytes: 16384 > btree space waste bytes: 144885 > file data blocks allocated: 2129063936 > referenced 1772728320 > > [CAUSE] > Btrfs-convert first collect all used blocks in the original fs, then > slightly enlarge the used blocks range as new btrfs data chunks. > > However the enlarge part has a problem, that it doesn't take the device > boundary into consideration. > > Thus it caused device extents and data chunks to go beyond device > boundary. > > [FIX] > Just to extra check before inserting data chunks into > btrfs_convert_context::data_chunk. > > Reported-by: Jiachen YANG <farseerfc@xxxxxxxxx> > Signed-off-by: Qu Wenruo <wqu@xxxxxxxx> With the minor tweaks, added to devel, thanks.
