From: Ming Lei <ming.lei@redhat.com>
To: Qu Wenruo <wqu@suse.de>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>
Subject: Re: About `bio->bi_iter.bi_size` at write endio time
Date: Tue, 15 Jun 2021 16:37:09 +0800 [thread overview]
Message-ID: <YMhmtd8doc9g23cT@T590> (raw)
In-Reply-To: <18cbcd0b-8c49-00b8-558b-5d74b3664b85@suse.de>
On Tue, Jun 15, 2021 at 03:22:59PM +0800, Qu Wenruo wrote:
> Hi,
>
> Recently I got a strange case where for write bio, at its endio time, I got
> bio->bi_iter.bi_size == 0, but bio_for_each_segment_all() reports we still
> have some bv_len.
It is normal to observe zero .bi_size in ->bi_end_io(), see req_bio_endio().
Meantime bio_for_each_segment_all() covers all pages added to the bio via
bio_add_page(), which is invariant after the bio is submitted.
>
> And obviously, when the bio get submitted, its bi_size is not 0.
>
> This is especially common for REQ_OP_ZONE_APPEND bio, but I also get rare
> bi_size == 0 at endio time, for REQ_OP_WRITE too.
It shouldn't be rare.
>
> So I guess bi_size at endio time is no longer reliable due to bio
> merging/splitting?
No, ->bi_size should be zero in .bi_end_io() if this bio is completed
successfully no matter if the bio is splitted or not.
>
> Thus the only correct way to get how large a bio really is, is through
> bio_for_each_segment_all()?
Yeah, if you mean to get the bio's real size in ->bi_end_io().
Thanks,
Ming
prev parent reply other threads:[~2021-06-15 8:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-15 7:22 About `bio->bi_iter.bi_size` at write endio time Qu Wenruo
2021-06-15 8:37 ` Ming Lei [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=YMhmtd8doc9g23cT@T590 \
--to=ming.lei@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=wqu@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).