From: Christoph Hellwig <hch@infradead.org>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: use IOMAP_DIO_BOUNCE flag for direct reads
Date: Mon, 31 Aug 2026 00:15:01 -0700 [thread overview]
Message-ID: <apUp9SjdTSAmmzXV@infradead.org> (raw)
In-Reply-To: <1219d8d9ed105a922d9af6130e08532e2907ea17.1787909265.git.wqu@suse.com>
On Fri, Aug 28, 2026 at 06:58:16PM +0930, Qu Wenruo wrote:
> Similar to direct writes, if the inode requires data checksum, we should
> use a stable buffer for IO, or even for direct reads an unstable buffer
> (e.g. the buffer is being modified during the direct read) can lead to
> checksum mismatch and even cause read failure.
>
> To address the potential problems of unstable dio read buffers, use
> IOMAP_DIO_BOUNCE for dio reads if the inode requires data checksum.
>
> This will bring a small performance drop, around 7% for my benchmark,
> which is definitely observable on modern NVME SSDs, but the overhead is
> still much smaller compared to data checksum:
Please take a look at the "lazy bounce buffering for checksummed reads"
series I just sent v2 of.
For one this removes the read-side IOMAP_DIO_BOUNCE support you are
using here, because it had problems. The alternative is iomap-based
and better at building large, aligned read bios which matter for HDD.
It also introduces the concept of lazy bouncing where it only bounce
buffers after a checksum failure happens by default, which means you
only pay an overhead for misbehaving applications. And unlike for
writes where they do exist in real life, I don't know any that modify
the buffer they read into.
next prev parent reply other threads:[~2026-08-31 7:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 9:28 [PATCH] btrfs: use IOMAP_DIO_BOUNCE flag for direct reads Qu Wenruo
2026-08-28 13:26 ` Wang Yugui
2026-08-31 7:15 ` Christoph Hellwig [this message]
2026-08-31 7:31 ` Qu Wenruo
2026-08-31 7:54 ` Johannes Thumshirn
2026-08-31 8:09 ` 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=apUp9SjdTSAmmzXV@infradead.org \
--to=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--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.