On 2020/9/24 上午3:41, Martin Steigerwald wrote:

Qu Wenruo - 23.09.20, 01:17:01 CEST:

quoted

On 2020/9/22 下午11:48, Martin Steigerwald wrote:

quoted

Qu Wenruo - 22.09.20, 12:34:18 CEST:

quoted

On 2020/9/22 下午6:20, Martin Steigerwald wrote:

quoted

Instead of the tool, can I also patch my kernel with the patch
below
to have it automatically fix it?

Sure, this one is a little safer than the tool.

[…]

quoted

quoted

quoted

quoted

If so, which approach would you prefer for testing?
I can apply the patch as I compile kernels myself.

That's great.

That should solve the problem.

And if you don't like the legacy root item, just do a balance (no
matter data or metadata), and that legacy root item will be
converted to current one, and even affected kernel won't report
any error any more.

Can I get away with a minimal balance? Or does it need to be a full
one?

Minimal is enough.
You just need to balance one chunk.

You can confirm it with "btrfs ins dump-tree -t root <device>".
If DATA_RELOC_TREE item size is still 249, it's legacy one.
If it's 429, then it's the current one.

Hmmm its 439. So is that good as well?

Sorry, 439 is the correct size.

        item 178 key (DATA_RELOC_TREE ROOT_ITEM 0) itemoff 8546 itemsize 439
                generation 13246 root_dirid 256 bytenr 896876544 level 0 refs 1
                lastsnap 0 byte_limit 0 bytes_used 16384 flags 0x0(none)
                uuid […]
                drop key (0 UNKNOWN.0 0) level 0

What is this tree used for by the way?

Used as a tree storing the new relocated chunk data.

If you like I can test with unpatched kernel whether warning goes away, but
I bet it may not be needed.

It should be safe now.

Thanks,
Qu

[…]