On Sat, Jan 23, 2021 at 08:08:01AM +1100, Dave Chinner wrote: > That is, we already elide the call to generic_write_sync() in direct > IO in the case that the device supports FUA and it's a pure > overwrite with no dirty metadata on the inode. Hence for a lot of > storage and AIO/io_uring+DIO w/ O_DSYNC workloads we're already > eliding this fsync-based lock cycle. > > In the case where we can't do a REQ_FUA IO because it is not > supported by the device, then don't we really only need a cache > flush at IO completion rather than the full generic_write_sync() > call path? That would provide this optimisation to all the > filesystems using iomap_dio_rw(), not just XFS.... > > In fact, I wonder if we need to do anything other than just use > REQ_FUA unconditionally in iomap for this situation, as the block > layer will translate REQ_FUA to a write+post-flush if the device > doesn't support FUA writes directly. > > You're thoughts on that, Christoph? For the pure overwrite O_DIRECT + O_DSYNC case we'd get away with just a flush. And using REQ_FUA will get us there, so it might be worth a try.
