Re: [PATCH 05/10] btrfs-progs: Pull free space tree related code from kernel

[Omar Sandoval <osandov@osandov.com>]

On Thu, Oct 04, 2018 at 09:34:01PM +0300, Nikolay Borisov wrote:
> 
> 
> On  4.10.2018 21:26, Omar Sandoval wrote:
> > On Mon, Oct 01, 2018 at 05:46:16PM +0300, Nikolay Borisov wrote:
> >> To help implement free space tree checker in user space some kernel
> >> function are necessary, namely iterating/deleting/adding freespace
> >> items, some internal search functions. Functions to populate a block
> >> group based on the extent tree. The code is largely copy/paste from
> >> the kernel with locking eliminated (i.e free_space_lock). It supports
> >> reading/writing of both bitmap and extent based FST trees.
> > 
> > For some reason, a lot of this added code uses spaces instead of tabs,
> > so I had to fix that in order to compare it to the kernel code (some of
> > the functions were reordered, too).
> > 
> > The only functional difference I noticed was that this is missing the
> > code to insert the block group header in the free space tree:
> > 
> > 	if (block_group->needs_free_space) {
> > 		ret = __add_block_group_free_space(trans, block_group, path);
> > 		if (ret)
> > 			return ret;
> > 	}
> > 
> > Was that intentionally omitted? Without it, the free space tree is
> > pretty broken :(
> 
> Yes, it was intentional. If you remember I even emailed you about this
> particular piece of code and you said you needed to have it this way in
> case delayed refs were run before the space tree was initialized.
> 
> In user space AFAIK we don't have that problem since
> add_new_free_space_info/__add_to_free_space_tree is called via
> 
> btrfs_Create_free_space_tree
>    populate_free_space_tree
>      add_new_free_space_info
>      __add_to_free_space_tree

Ah, will progs never allocate a new block group? If so, then you're
right, this is fine.