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.
