All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>, Qu Wenruo <wqu@suse.com>,
	Naohiro Aota <naohiro.aota@wdc.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 03/10] btrfs: split btrfs_submit_data_bio
Date: Mon, 25 Apr 2022 19:16:21 +0800	[thread overview]
Message-ID: <bade7fa8-d95b-e0e8-0af8-e40fec341789@gmx.com> (raw)
In-Reply-To: <20220425110928.GA24430@lst.de>



On 2022/4/25 19:09, Christoph Hellwig wrote:
> On Mon, Apr 25, 2022 at 05:37:40PM +0800, Qu Wenruo wrote:
>> Oh, please don't completely get rid of btrfs_bio, even just for writes.
>>
>> The btrfs_bio::iter is pretty important for us to grab the original
>> logical bytenr of a bio.
>> As bio::bi_iter can be modified by lower level (does dm modifies it
>> too?), or btrfs itself.
>>
>> In fact, my incoming updated btrfs repair repair code heavily rely on
>> btrfs_bio::iter, both read and write, to grab the original logical
>> bytenr of the bio.
>
> Then it's doing the wrong thing.  I actually have a series to remove
> it entirely.

I'm wondering how would you iterate the bvec of a cloned bio then.

Regular bio_for_each_segment_all() will just trigger warning on cloned bio.
If you go something like chained bio, then any error would mark the
whole range error, and in fact my repair work is going to make
read-repair work with chained bio, thus I have to directly iterate
cloned bio anyway.

Just bio_for_each_segment()? That bi_iter is no longer reliable, just
btrfs_map_block() can modify it.

Anyway, what I really need is just a proper way to:

- Iterate bvecs of a clone bio
- Grab the original logical bytenr from a bio

If you can do that with extra members, I'm fine with alternative ways.

Thanks,
Qu

  reply	other threads:[~2022-04-25 11:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-25  7:54 cleanup btrfs bio handling, part 2 Christoph Hellwig
2022-04-25  7:54 ` [PATCH 01/10] btrfs: move more work into btrfs_end_bioc Christoph Hellwig
2022-04-26  7:19   ` Johannes Thumshirn
2022-04-25  7:54 ` [PATCH 02/10] btrfs: cleanup btrfs_submit_dio_bio Christoph Hellwig
2022-04-25  8:45   ` Qu Wenruo
2022-04-26  7:21   ` Johannes Thumshirn
2022-04-25  7:54 ` [PATCH 03/10] btrfs: split btrfs_submit_data_bio Christoph Hellwig
2022-04-25  9:11   ` Qu Wenruo
2022-04-25  9:19     ` Christoph Hellwig
2022-04-25  9:37       ` Qu Wenruo
2022-04-25 11:09         ` Christoph Hellwig
2022-04-25 11:16           ` Qu Wenruo [this message]
2022-04-25 11:19             ` Christoph Hellwig
2022-04-25 11:31               ` Qu Wenruo
2022-04-25 11:34                 ` Christoph Hellwig
2022-04-25 11:40                   ` Qu Wenruo
2022-04-25 11:43                     ` Qu Wenruo
2022-04-25 17:17                     ` Christoph Hellwig
2022-04-26  1:24                       ` Qu Wenruo
2022-04-25  7:54 ` [PATCH 04/10] btrfs: don't double-defer bio completions for compressed reads Christoph Hellwig
2022-04-25  7:54 ` [PATCH 05/10] btrfs: defer I/O completion based on the btrfs_raid_bio Christoph Hellwig
2022-04-25  7:54 ` [PATCH 06/10] btrfs: don't use btrfs_bio_wq_end_io for compressed writes Christoph Hellwig
2022-04-25  7:54 ` [PATCH 07/10] btrfs: centralize setting REQ_META Christoph Hellwig
2022-04-25  9:06   ` Qu Wenruo
2022-04-25  7:54 ` [PATCH 08/10] btrfs: remove btrfs_end_io_wq Christoph Hellwig
2022-04-25  7:54 ` [PATCH 09/10] btrfs: refactor btrfs_map_bio Christoph Hellwig
2022-04-25  8:56   ` Qu Wenruo
2022-04-25  9:17     ` Christoph Hellwig
2022-04-26 13:24     ` Christoph Hellwig
2022-04-25  7:54 ` [PATCH 10/10] btrfs: do not allocate a btrfs_bio for low-level bios Christoph Hellwig
2022-04-25  9:01   ` Qu Wenruo
2022-04-25  9:18     ` Christoph Hellwig
2022-04-29 14:30 cleanup btrfs bio handling, part 2 v2 Christoph Hellwig
2022-04-29 14:30 ` [PATCH 03/10] btrfs: split btrfs_submit_data_bio Christoph Hellwig
2022-05-26  7:36 cleanup btrfs bio handling, part 2 v4 Christoph Hellwig
2022-05-26  7:36 ` [PATCH 03/10] btrfs: split btrfs_submit_data_bio Christoph Hellwig

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=bade7fa8-d95b-e0e8-0af8-e40fec341789@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.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.