On Wed, May 23, 2018 at 10:32:13AM +0300, Nikolay Borisov wrote: > > > On 23.05.2018 10:29, Qu Wenruo wrote: > > When doing qgroup rescan using the following script (modified from > > btrfs/017 test case), we can sometimes hit qgroup corruption. > > > > ------ > > umount $dev &> /dev/null > > umount $mnt &> /dev/null > > > > mkfs.btrfs -f -n 64k $dev > > mount $dev $mnt > > > > extent_size=8192 > > > > xfs_io -f -d -c "pwrite 0 $extent_size" $mnt/foo > /dev/null > > btrfs subvolume snapshot $mnt $mnt/snap > > > > xfs_io -f -c "reflink $mnt/foo" $mnt/foo-reflink > /dev/null > > xfs_io -f -c "reflink $mnt/foo" $mnt/snap/foo-reflink > /dev/null > > xfs_io -f -c "reflink $mnt/foo" $mnt/snap/foo-reflink2 > /dev/unll > > btrfs quota enable $mnt > > > > # -W is the new option to only wait rescan while not starting new one > > btrfs quota rescan -W $mnt > > btrfs qgroup show -prce $mnt > > umount $mnt > > > > # Need to patch btrfs-progs to report qgroup mismatch as error > > btrfs check $dev || _fail > > ------ > > > > For fast machine, we can hit some corruption which missed accounting > > tree blocks: > > ------ > > qgroupid rfer excl max_rfer max_excl parent child > > -------- ---- ---- -------- -------- ------ ----- > > 0/5 8.00KiB 0.00B none none --- --- > > 0/257 8.00KiB 0.00B none none --- --- > > ------ > > > > This is due to the fact that we're always searching commit root for > > btrfs_find_all_roots() at qgroup_rescan_leaf(), but the leaf we get is > > from current transaction, not commit root. > > > > And if our tree blocks get modified in current transaction, we won't > > find any owner in commit root, thus causing the corruption. > > > > Fix it by searching commit root for extent tree for > > qgroup_rescan_leaf(). > > > > Reported-by: Nikolay Borisov <nborisov@xxxxxxxx> > > Signed-off-by: Qu Wenruo <wqu@xxxxxxxx> > > Reviewed-by: Nikolay Borisov <nborisov@xxxxxxxx> V3 replaced in misc-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
