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