All of lore.kernel.org
 help / color / mirror / Atom feed
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


      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 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.