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