On Fri, Apr 22, 2016 at 11:28:24AM +0300, Alex Lyakas wrote: > Hi Omar, Chris, > > I have reviewed the free-space-tree code. It is a very nice feature. > > However, I have a basic understanding question. > > Let's say we are running a delayed ref which inserts a new EXTENT_ITEM > into the extent tree, e.g., we are in alloc_reserved_file_extent. At > this point we call remove_from_free_space_tree(), which updates the > free-space-tree about the allocated space. But this requires to COW > the free-space-tree itself. So we allocate a new tree block for the > free-space tree, and insert a new delayed ref, which will update the > extent tree about the new tree block allocation. We also insert a > delayed ref to free the previous copy of the free-space-tree block. > > At some point we run these new delayed refs, so we insert/remove > EXTENT_ITEMs from the extent tree, and this in turn requires us to > update the free-space-tree again. So we need again to COW > free-space-tree blocks, generating more delayed refs. > > At which point this recursion stops? > > Do we assume that at some point all needed free-space tree blocks have > been COW'ed already, and we do not COW a tree block more than once per > transaction (unless it was written to disk due to memory pressure)? > > Thanks! > Alex. Hi, Alex, Your understanding is correct, we'll only COW a tree block once during a transaction, so the recursion stops once all of the free space items we need to add/remove don't require rebalancing the tree or allocating or freeing a block. Same thing goes for extent items in the extent tree. Since the extent tree and free space tree items are much smaller than a tree block, this doesn't turn out to be a problem in practice. Thanks for taking a look :) -- Omar -- 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
