On 1/24/21 8:14 AM, David Sterba wrote:
On Fri, Jan 15, 2021 at 04:26:17PM -0500, Josef Bacik wrote:
While running btrfs/011 in a loop I would often ASSERT() while trying to
add a new free space entry that already existed, or get an -EEXIST while
adding a new block to the extent tree, which is another indication of
double allocation.
This occurs because when we do the free space tree population, we create
the new root and then populate the tree and commit the transaction.
The problem is when you create a new root, the root node and commit root
node are the same. During this initial transaction commit we will run
all of the delayed refs that were paused during the free space tree
generation, and thus begin to cache block groups. While caching block
groups the caching thread will be reading from the main root for the
free space tree, so as we make allocations we'll be changing the free
space tree, which can cause us to add the same range twice which results
in either the ASSERT(ret != -EEXIST); in __btrfs_add_free_space, or in a
Still no stacktraces but at least this gives some pointer to the code
which assert is hit.
Sorry I meant to put this in the changelog for the patch but forgot. I tried to
reproduce the problem for a day on a couple of boxes but couldn't, and I had
lost the original logs. Next time I'll capture the stacktraces themselves, but
I remembered which ASSERT() it was so just noted that in the log. Thanks,
Josef
