From: David Sterba <dsterba@suse.cz>
To: Christoph Hellwig <hch@lst.de>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>, Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 4/5] btrfs: do not return errors from btrfs_submit_compressed_read
Date: Wed, 20 Apr 2022 22:45:16 +0200 [thread overview]
Message-ID: <20220420204516.GK1513@twin.jikos.cz> (raw)
In-Reply-To: <20220416044920.GB6162@lst.de>
On Sat, Apr 16, 2022 at 06:49:20AM +0200, Christoph Hellwig wrote:
> On Sat, Apr 16, 2022 at 06:48:37AM +0800, Qu Wenruo wrote:
> > More and more bio submit functions are returning void and endio of the bio.
> >
> > But there are still quite some not doing this, like btrfs_map_bio().
> >
> > I'm wondering at which boundary we should return void and handle
> > everything in-house?
>
> I don't think it is quite clear. All the I/O errors with a bio should
> be handled through end_io, and we already have that, module the compressed
> case with it's extra layer of bios. Now at what point we call the
> endio handler is a different question. Duplicating it everywhere is
> a bit annoying, so having some low-level helpers that just return an
> error might be useful. I plan a fair amount of refactoring around
> btrfs_map_bio, so I'll see if lifting the end_io call into it might
> or might no make sense while I'm at it.
Please try to limit number of patches in a series to 10ish, this works
much better when there's something to change in the early patches or
everything is fine and it will get merged for testing. Also there are
always other patches in flux so this helps me to schedule. Thanks.
next prev parent reply other threads:[~2022-04-20 20:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-15 14:33 minor bio submission cleanups Christoph Hellwig
2022-04-15 14:33 ` [PATCH 1/5] btrfs: move btrfs_readpage to extent_io.c Christoph Hellwig
2022-04-15 14:33 ` [PATCH 2/5] btrfs: remove the unused bio_flags argument to btrfs_submit_metadata_bio Christoph Hellwig
2022-04-15 22:35 ` Qu Wenruo
2022-04-15 14:33 ` [PATCH 3/5] btrfs: do not return errors from btrfs_submit_metadata_bio Christoph Hellwig
2022-04-15 22:40 ` Qu Wenruo
2022-04-15 14:33 ` [PATCH 4/5] btrfs: do not return errors from btrfs_submit_compressed_read Christoph Hellwig
2022-04-15 22:48 ` Qu Wenruo
2022-04-16 4:49 ` Christoph Hellwig
2022-04-16 6:48 ` Qu Wenruo
2022-04-20 20:45 ` David Sterba [this message]
2022-04-15 14:33 ` [PATCH 5/5] btrfs: do not return errors from submit_bio_hook_t instances Christoph Hellwig
2022-04-15 22:49 ` Qu Wenruo
2022-04-15 22:44 ` minor bio submission cleanups Qu Wenruo
2022-04-16 4:46 ` Christoph Hellwig
2022-04-18 7:23 ` Nikolay Borisov
2022-04-20 19:28 ` 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=20220420204516.GK1513@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=dsterba@suse.com \
--cc=hch@lst.de \
--cc=josef@toxicpanda.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox