All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Linux FS Devel <linux-fsdevel@vger.kernel.org>, dm-devel@redhat.com
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Any bio_clone_slow() implementation which doesn't share bi_io_vec?
Date: Tue, 23 Nov 2021 14:44:32 +0800	[thread overview]
Message-ID: <5d8351f1-1b09-bff0-02f2-a417c1669607@gmx.com> (raw)

Hi,

Although there are some out-of-date comments mentions other
bio_clone_*() variants, but there isn't really any other bio clone
variants other than __bio_clone_fast(), which shares bi_io_vec with the
source bio.

This limits means we can't free the source bio before the cloned one.

Is there any bio_clone variant which do a deep clone, including bi_io_vec?



The background story is a little long, with btrfs involved.

Unlike dm/md-raid which uses bio_split(), btrfs splits its bio before
even creating a bio.
Every time btrfs wants to create a bio, it will calculate the boundary,
thus will only create a bio which never cross various raid boundary.

But this is not really the common practice, I'd like to at least change
the timing of bio split so that reflects more like dm/md raid.

That's why the bio_clone thing is involved, there is still some corner
cases that we don't want to fail the whole large bio if there is only
one stripe failed (mostly for read bio, that we want to salvage as much
data as possible)

Thus regular bio_split() + bio_chain() solution is not that good here.

Any idea why no such bio_clone_slow() or bio_split_slow() provided in
block layer?

Or really bio_split() + bio_chain() is the only recommended solution?

Thanks,
Qu

WARNING: multiple messages have this Message-ID (diff)
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Linux FS Devel <linux-fsdevel@vger.kernel.org>, dm-devel@redhat.com
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: [dm-devel] Any bio_clone_slow() implementation which doesn't share bi_io_vec?
Date: Tue, 23 Nov 2021 14:44:32 +0800	[thread overview]
Message-ID: <5d8351f1-1b09-bff0-02f2-a417c1669607@gmx.com> (raw)

Hi,

Although there are some out-of-date comments mentions other
bio_clone_*() variants, but there isn't really any other bio clone
variants other than __bio_clone_fast(), which shares bi_io_vec with the
source bio.

This limits means we can't free the source bio before the cloned one.

Is there any bio_clone variant which do a deep clone, including bi_io_vec?



The background story is a little long, with btrfs involved.

Unlike dm/md-raid which uses bio_split(), btrfs splits its bio before
even creating a bio.
Every time btrfs wants to create a bio, it will calculate the boundary,
thus will only create a bio which never cross various raid boundary.

But this is not really the common practice, I'd like to at least change
the timing of bio split so that reflects more like dm/md raid.

That's why the bio_clone thing is involved, there is still some corner
cases that we don't want to fail the whole large bio if there is only
one stripe failed (mostly for read bio, that we want to salvage as much
data as possible)

Thus regular bio_split() + bio_chain() solution is not that good here.

Any idea why no such bio_clone_slow() or bio_split_slow() provided in
block layer?

Or really bio_split() + bio_chain() is the only recommended solution?

Thanks,
Qu


--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


             reply	other threads:[~2021-11-23  6:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-23  6:44 Qu Wenruo [this message]
2021-11-23  6:44 ` [dm-devel] Any bio_clone_slow() implementation which doesn't share bi_io_vec? Qu Wenruo
2021-11-23  7:43 ` Christoph Hellwig
2021-11-23  7:43   ` [dm-devel] " Christoph Hellwig
2021-11-23  8:10   ` Qu Wenruo
2021-11-23  8:10     ` [dm-devel] " Qu Wenruo
2021-11-23  8:13     ` Christoph Hellwig
2021-11-23  8:13       ` [dm-devel] " Christoph Hellwig
2021-11-23 11:09       ` Qu Wenruo
2021-11-23 11:09         ` [dm-devel] " Qu Wenruo
2021-11-23 11:39         ` Johannes Thumshirn
2021-11-23 11:39           ` [dm-devel] " Johannes Thumshirn
2021-11-23 14:28           ` hch
2021-11-23 14:28             ` [dm-devel] " hch
2021-11-23 23:07             ` Qu Wenruo
2021-11-23 23:07               ` [dm-devel] " Qu Wenruo
2021-11-24  6:09               ` hch
2021-11-24  6:09                 ` [dm-devel] " hch
2021-11-24  6:18                 ` Qu Wenruo
2021-11-24  6:18                   ` [dm-devel] " Qu Wenruo
2021-11-24  7:02                   ` hch
2021-11-24  7:02                     ` [dm-devel] " hch
2021-11-24  7:22                     ` hch
2021-11-24  7:22                       ` [dm-devel] " hch
2021-11-24  7:25               ` Naohiro Aota
2021-11-24  7:25                 ` [dm-devel] " Naohiro Aota
2021-11-24  7:39                 ` Qu Wenruo
2021-11-24  7:39                   ` [dm-devel] " Qu Wenruo
2021-11-26 12:33       ` Qu Wenruo
2021-11-26 12:33         ` 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=5d8351f1-1b09-bff0-02f2-a417c1669607@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /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.