From: Christoph Hellwig <hch@lst.de>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Christoph Hellwig <hch@lst.de>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/3] btrfs: pass the btrfs_bio_ctrl to submit_one_bio
Date: Mon, 6 Jun 2022 08:30:50 +0200 [thread overview]
Message-ID: <20220606063050.GA2308@lst.de> (raw)
In-Reply-To: <ee3f0a66-ce9d-5e3d-2a8e-fd620bcb5f5d@gmx.com>
On Sun, Jun 05, 2022 at 06:31:18AM +0800, Qu Wenruo wrote:
> In fact the only call sites really caring num_mirror is the metadata
> read path (as it doesn't rely on the read-repair code, since metadata
> has inline csum and it has a different validation condition).
>
> It may be a good idea to make a union for btrfs_bio, to contain all the
> needed info for metadata verification (btrfs_key, transid, level), so
> that we can get rid of the num_mirror parameter for submit_extent_page()
> completely.
My idea was to pass that in structure in bio->bi_private. But that
is just thought for now, I've not tried to actually implement it yet.
next prev parent reply other threads:[~2022-06-06 6:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 7:11 extent_io bio submission cleanup Christoph Hellwig
2022-06-03 7:11 ` [PATCH 1/3] btrfs: don't use bio->bi_private to pass the inode to submit_one_bio Christoph Hellwig
2022-06-03 10:33 ` Qu Wenruo
2022-06-03 7:11 ` [PATCH 2/3] btrfs: merge end_write_bio and flush_write_bio Christoph Hellwig
2022-06-03 10:40 ` Qu Wenruo
2022-06-03 7:11 ` [PATCH 3/3] btrfs: pass the btrfs_bio_ctrl to submit_one_bio Christoph Hellwig
2022-06-04 22:31 ` Qu Wenruo
2022-06-06 6:30 ` Christoph Hellwig [this message]
2022-06-06 10:41 ` Nikolay Borisov
2022-06-06 16:29 ` Christoph Hellwig
2022-06-06 20:23 ` David Sterba
2022-06-06 20:26 ` extent_io bio submission cleanup David Sterba
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=20220606063050.GA2308@lst.de \
--to=hch@lst.de \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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.