On Fri, May 04, 2018 at 01:56:59PM +0800, Qu Wenruo wrote: > Under the following case, qgroup rescan can double account cowed tree > blocks: > > In this case, extent tree only has one tree block. > > - > | transid=5 last committed=4 > | btrfs_qgroup_rescan_worker() > | |- btrfs_start_transaction() > | | transid = 5 > | |- qgroup_rescan_leaf() > | |- btrfs_search_slot_for_read() on extent tree > | Get the only extent tree block from commit root (transid = 4). > | Scan it, set qgroup_rescan_progress to the last > | EXTENT/META_ITEM + 1 > | now qgroup_rescan_progress = A + 1. > | > | fs tree get CoWed, new tree block is at A + 16K > | transid 5 get committed > - > | transid=6 last committed=5 > | btrfs_qgroup_rescan_worker() > | btrfs_qgroup_rescan_worker() > | |- btrfs_start_transaction() > | | transid = 5 > | |- qgroup_rescan_leaf() > | |- btrfs_search_slot_for_read() on extent tree > | Get the only extent tree block from commit root (transid = 5). > | scan it using qgroup_rescan_progress (A + 1). > | found new tree block beyong A, and it's fs tree block, > | account it to increase qgroup numbers. > - > > In above case, tree block A, and tree block A + 16K get accounted twice, > while qgroup rescan should stop when it already reach the last leaf, > other than continue using its qgroup_rescan_progress. > > Such case could happen by just looping btrfs/017 and with some > possibility it can hit such double qgroup accounting problem. > > Fix it by checking the path to determine if we should finish qgroup > rescan, other than relying on next loop to exit. > > Reported-by: Nikolay Borisov <[email protected]> > Signed-off-by: Qu Wenruo <[email protected]>
Is this something for 4.17-rc ? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
