From: Christoph Hellwig <hch@infradead.org>
To: Zhenxian Ma <1604099876@qq.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@infradead.org>,
linux-block@vger.kernel.org, mzx199711@gmail.com,
Zhenxian Ma <mazhenxian@xiaohongshu.com>
Subject: Re: [PATCH v2 2/2] block: only use REQ_FUA for direct writes if the device supports it
Date: Mon, 17 Aug 2026 02:21:38 -0700 [thread overview]
Message-ID: <aoLSovrhs5H1y34L@infradead.org> (raw)
In-Reply-To: <tencent_A41247F29AC0971AE96B52964BE4491B440A@qq.com>
On Sat, Aug 15, 2026 at 08:02:15PM +0800, Zhenxian Ma wrote:
> From: Zhenxian Ma <mzx199711@gmail.com>
>
> When a block device does not support FUA natively, the block layer
> emulates it by adding a cache flush to every write bio. An O_DSYNC
> direct write that spans N bios then costs N flushes, rather than the
> single generic_write_sync() issued after the write completes.
>
> Introduce blkdev_dio_fua() to decide when REQ_FUA is set. A synchronous
> write can rely on generic_write_sync() when the device lacks FUA, so it
> sets REQ_FUA only when bdev_fua() is true. An asynchronous write
> completes in blkdev_bio_end_io() and cannot call the blocking
> generic_write_sync(), so it keeps REQ_FUA (emulated when needed) to stay
> durable.
>
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Zhenxian Ma <mzx199711@gmail.com>
> Signed-off-by: Zhenxian Ma <mazhenxian@xiaohongshu.com>
> ---
> block/fops.c | 32 +++++++++++++++++++++++++++-----
> 1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/block/fops.c b/block/fops.c
> index a2c3af38106b..e7d073620271 100644
> --- a/block/fops.c
> +++ b/block/fops.c
> @@ -26,12 +26,26 @@ static inline struct inode *bdev_file_inode(struct file *file)
> return file->f_mapping->host;
> }
>
> -static blk_opf_t dio_bio_write_op(struct kiocb *iocb)
> +static bool blkdev_dio_fua(struct kiocb *iocb, struct block_device *bdev)
> +{
> + if (!iocb_is_dsync(iocb))
> + return false;
> + /*
> + * Async writes cannot fall back to generic_write_sync(), so they must
> + * use FUA (emulated if needed); sync writes only need it when the
> + * device supports FUA natively.
> + */
Ah, I guess this explain why the original code unconditionally uses FUA.
Let's hope no one cares about the performance of large async writes
on devices without FUA.
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
prev parent reply other threads:[~2026-08-17 9:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 13:03 [PATCH] block: skip redundant flush for O_DSYNC direct writes Zhenxian Ma
2026-08-12 16:42 ` Christoph Hellwig
2026-08-13 7:35 ` 马振先
2026-08-14 6:32 ` Christoph Hellwig
2026-08-15 9:06 ` [PATCH v2 0/2] block: avoid redundant flushes " Zhenxian Ma
2026-08-15 9:06 ` [PATCH v2 1/2] block: skip redundant flush " Zhenxian Ma
2026-08-17 9:19 ` Christoph Hellwig
2026-08-15 12:02 ` [PATCH v2 2/2] block: only use REQ_FUA for direct writes if the device supports it Zhenxian Ma
2026-08-17 9:21 ` Christoph Hellwig [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=aoLSovrhs5H1y34L@infradead.org \
--to=hch@infradead.org \
--cc=1604099876@qq.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=mazhenxian@xiaohongshu.com \
--cc=mzx199711@gmail.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.