Re: [PATCH 00/19] btrfs: Move generic backref cache build functions to backref.c

David Sterba
2020-03-04T13:40:36Z

On Wed, Mar 04, 2020 at 12:54:24PM +0800, Qu Wenruo wrote:
>
>
> On 2020/3/4 上午5:22, Josef Bacik wrote:
> > On 3/3/20 2:13 AM, Qu Wenruo wrote:
> >> The patchset is based on previous backref_cache_refactor branch, which
> >> is further based on misc-next.
> >>
> >> The whole series can be fetched from github:
> >> https://github.com/adam900710/linux/tree/backref_cache_code_move
> >>
> >> All the patches in previous branch is not touched at all, thus they are
> >> not re-sent in this patchset.
> >>
> >>
> >> Currently there are 3 major parts of build_backref_tree():
> >> - ITERATION
> >>    This will do a breadth-first search, starts from the target bytenr,
> >>    and queue all parents into the backref cache.
> >>    The result is a temporary map, which is only single-directional, and
> >>    involved new backref nodes are not yet inserted into the cache.
> >>
> >> - WEAVING
> >>    Finish the map to make it bi-directional, and insert new nodes into
> >>    the cache.
> >>
> >> - CLEANUP
> >>    Cleanup the useless nodes, either remove it completely or add them
> >>    into the cache as detached.
> >>
> >
> > I've found a bunch of bugs in the backref code while fixing Zygo's
> > problem, you are probably going to want to wait for my patches to go in
> > before you start moving things around, because it's going to conflict a
> > bunch.  Thanks,
>
> No problem, it's expected to have some comments even for previous patchset.
>
> So rebasing is expected.

The fixes get merged first so they can be applied to older stable trees,
the cleanups that move code are best done as the last thing in the patch
queue. So this depends on timing and the amount of conflicts but we have
like 2 rcs to go.