From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/2] btrfs: do most metadata parentnesss check at endio time
Date: Fri, 11 Nov 2022 17:07:18 +0100 [thread overview]
Message-ID: <20221111160718.GT5824@twin.jikos.cz> (raw)
In-Reply-To: <cover.1663133223.git.wqu@suse.com>
On Wed, Sep 14, 2022 at 01:32:49PM +0800, Qu Wenruo wrote:
> [BACKGROUND]
>
> Btrfs metadata and data verification are both done at endio time.
>
> But metadata has its own extra verifiaction, mostly related to
> parentness check, done at btrfs_read_extent_buffer() and
> read_tree_block().
>
> This is not a big deal, but if we want to make metadata read-repair to
> share the same code base with data, we may want the metadata parentness
> check also to happen at endio time.
>
> [ENHANCEMENT]
>
> This patchset will move all the parentness check code into
> btrfs_validate_metadata_buffer().
>
> As the first step, the first patch will concentrate all the existing
> parentness check into one structure.
>
> Then the second patch will pass all the parentness info into btrfs_bio,
> using the shared space of data csum, so at endio time we can grab all
> the metadata parentness info and do the verification.
>
> This means the following mismatch at read time would be rejected
> directly:
>
> - First key mismatch
> - Transid mismatch
> - Level mismatch
> - Owner root mismatch
>
> Since all the read-time parentness check is all done at endio now,
> btrfs_read_extent_buffer() can do less verification work for new extent
> buffers which is going to be read from disk.
>
> But please note that, we still do parentness check for cached extent
> buffer, to avoid some cached/stale extent buffer read by other parent
> tree blocks to cause problems.
>
> Thankfully that part will not trigger read repair thus won't affect us
> for now.
>
> [TODO]
> Make metadata and data share the same code base to do read-repair.
>
> The main blockage here is, we have a lot of pending patches changing
> the read-repair code, thus it's going to cause conflicts for the already
> lengthy pending patches.
>
> Thus the refactor part is sent out first, then after read-repair is
> settled down, I can work on the unified read-repair code.
>
> Qu Wenruo (2):
> btrfs: concentrate all tree block parentness check parameters into one
> structure
> btrfs: move tree block parentness check into validate_extent_buffer()
As this is only 2 patches and they apply with minimal conflicts I've
added it to misc-next, thanks.
prev parent reply other threads:[~2022-11-11 16:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-14 5:32 [PATCH 0/2] btrfs: do most metadata parentnesss check at endio time Qu Wenruo
2022-09-14 5:32 ` [PATCH 1/2] btrfs: concentrate all tree block parentness check parameters into one structure Qu Wenruo
2022-11-11 16:09 ` David Sterba
2022-09-14 5:32 ` [PATCH 2/2] btrfs: move tree block parentness check into validate_extent_buffer() Qu Wenruo
2022-11-11 16:07 ` David Sterba [this message]
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=20221111160718.GT5824@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox