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