From: Martin Steigerwald <martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org, Qu Wenruo <quwenruo.btrfs@gmx.com>,
Qu Wenruo <wqu@suse.com>
Subject: Re: [PATCH] btrfs: fix false alert caused by legacy btrfs root item
Date: Wed, 23 Sep 2020 21:41:48 +0200 [thread overview]
Message-ID: <1952994.EpAzVLkqvi@merkaba> (raw)
In-Reply-To: <ec3a5769-a847-6b3d-d502-b96c053b070f@suse.com>
Qu Wenruo - 23.09.20, 01:17:01 CEST:
> On 2020/9/22 下午11:48, Martin Steigerwald wrote:
> > Qu Wenruo - 22.09.20, 12:34:18 CEST:
> >> On 2020/9/22 下午6:20, Martin Steigerwald wrote:
> >>> 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.
[…]
> >>> 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?
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?
If you like I can test with unpatched kernel whether warning goes away, but
I bet it may not be needed.
[…]
--
Martin
next prev parent reply other threads:[~2020-09-23 19:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 2:37 [PATCH] btrfs: fix false alert caused by legacy btrfs root item Qu Wenruo
2020-09-22 10:20 ` Martin Steigerwald
2020-09-22 10:34 ` Qu Wenruo
2020-09-22 15:48 ` Martin Steigerwald
2020-09-22 23:17 ` Qu Wenruo
2020-09-23 19:41 ` Martin Steigerwald [this message]
2020-09-24 0:07 ` Qu Wenruo
2020-09-24 6:17 ` Martin Steigerwald
2020-09-22 17:17 ` Martin Steigerwald
2020-09-22 11:12 ` kernel test robot
2020-09-22 11:31 ` Qu Wenruo
2020-09-22 11:31 ` Qu Wenruo
2020-09-22 20:51 ` Josef Bacik
2020-09-23 6:23 ` kernel test robot
2020-09-23 6:23 ` kernel test robot
2020-09-23 9:31 ` David Sterba
2020-09-23 9:31 ` David Sterba
2020-09-23 10:28 ` Qu Wenruo
2020-09-23 17:08 ` David Sterba
2020-09-23 17:08 ` David Sterba
2020-09-23 9:43 ` David Sterba
2020-10-05 15:29 ` Martin Steigerwald
2020-10-06 0:19 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1952994.EpAzVLkqvi@merkaba \
--to=martin@lichtvoll.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.