From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christoph Hellwig <hch@infradead.org>, 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 17:01:21 +0930 [thread overview]
Message-ID: <74188ab7-96d7-4536-997f-926a5a845f79@gmx.com> (raw)
In-Reply-To: <apUp9SjdTSAmmzXV@infradead.org>
在 2026/8/31 16:45, Christoph Hellwig 写道:
> 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.
Thanks for pointing to that series.
However it only shows up in lore, but not in my inbox at all, and I have
no idea why.
And lore is never a good way to review patches, nor easy to reply.
>
> 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.
In that case I'm afraid btrfs may need some way to integrate the
checksum handling into iomap.
As the btrfs has a very internal handling for repairing each block.
> And unlike for
> writes where they do exist in real life, I don't know any that modify
> the buffer they read into.
Yep, and that's why we didn't put too much attention to dio reads until
the dio writes bounce is implemented.
Thanks,
Qu
next prev parent reply other threads:[~2026-08-31 7:31 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
2026-08-31 7:31 ` Qu Wenruo [this message]
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=74188ab7-96d7-4536-997f-926a5a845f79@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox