On Tue, Jun 07, 2022 at 04:06:53PM +0000, Al Viro wrote: > On Tue, Jun 07, 2022 at 06:42:17AM +0200, Christoph Hellwig wrote: > > > > diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c > > > index 370c3241618a..0f16479b13d6 100644 > > > --- a/fs/iomap/direct-io.c > > > +++ b/fs/iomap/direct-io.c > > > @@ -548,7 +548,7 @@ __iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter, > > > } > > > > > > /* for data sync or sync, we need sync completion processing */ > > > - if (iocb->ki_flags & IOCB_DSYNC) > > > + if (iocb->ki_flags & IOCB_DSYNC && !(dio_flags & IOMAP_DIO_NOSYNC)) > > > > Same here. > > Dealt with in the next commit, actually. > > > Also the FUA check below needs to check IOMAP_DIO_NOSYNC as > > well. > > Does it? AFAICS, we don't really care about REQ_FUA on any requests - what > btrfs hack tries to avoid is stepping into > if (ret > 0 && (dio->flags & IOMAP_DIO_NEED_SYNC)) > ret = generic_write_sync(iocb, ret); > with generic_write_sync() called by btrfs_do_write_iter() after it has > dropped the lock held through btrfs_direct_write(). Do we want to > suppress REQ_FUA on the requests generated by __iomap_dio_rw() in > that case (DSYNC, !SYNC)? Confused... Anyway, updated branch force-pushed...
