On Fri, Feb 19, 2021 at 05:12:12PM +0100, Holger Hoffstätte wrote:
> On 2021-02-19 16:20, Wang Yugui wrote:
> > --- a/fs/btrfs/ctree.h
> > +++ b/fs/btrfs/ctree.h
> > @@ -146,6 +146,9 @@ enum {
> > BTRFS_FS_STATE_DEV_REPLACING,
> > /* The btrfs_fs_info created for self-tests */
> > BTRFS_FS_STATE_DUMMY_FS_INFO,
> > +
> > + /* Indicate that we can't trust the free space tree for caching yet */
> > + BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED,
> > };
> >
> > #define BTRFS_BACKREF_REV_MAX 256
> >
> > Both the line(Line:146 vs Line:564) and the content are wrong.
> >
>
> Ahh..now I understand, indeed the merge of BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED
> went into
> the wrong enum. I misunderstood your original posting to mean that it had
> somehow missed
> a chunk or used the wrong enum value in set_bit.
>
> Anyway, good catch! I guess Dave needs to decide how to fix this, maybe
> let Greg revert & re-apply properly.
>
> Can anybody explain why git decided to do this?
Git finds that the patch does not apply and lets the user to fix it.
I did git cherry-pick of 2f96e40212d435b3284 on v5.10.12 and got 2
conflicts:
first was in caching_thread around
if (btrfs_fs_compat_ro(fs_info, FREE_SPACE_TREE))
that got resolved correctly, and the second one in the enum, but the
conflict was suggested in the right enum (lines 559+), so all I had to
do was to remove unmatched context and the <<< >>> markers. It's
possible that git version could affect that, mine is 2.29.2. Or stable
team does not use git for the intermediate patches and quilt did not get
it right.
I doubt that the conflict resolution was done incorrectly by hand, the
enums are quite far away so it would not be just a trivial change (like
context fixups) that are in the scope of semi-automatic stable
backports.
