Re: [PATCH v2 2/2] block: only use REQ_FUA for direct writes if the device supports it

Christoph Hellwig <[email protected]>
Newsgroups org.kernel.vger.linux-block
Message-ID <[email protected]>
On Sat, Aug 15, 2026 at 08:02:15PM +0800, Zhenxian Ma wrote:
> From: Zhenxian Ma <[email protected]>
> 
> 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 <[email protected]>
> Signed-off-by: Zhenxian Ma <[email protected]>
> Signed-off-by: Zhenxian Ma <[email protected]>
> ---
>  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 <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.