Re: RFC: iomap write invalidation

Darrick J. Wong
2020-07-21T15:59:40Z

On Tue, Jul 21, 2020 at 05:41:32PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 21, 2020 at 08:27:54AM -0700, Darrick J. Wong wrote:
> > On Tue, Jul 21, 2020 at 05:16:16PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 21, 2020 at 04:14:37PM +0100, Matthew Wilcox wrote:
> > > > On Tue, Jul 21, 2020 at 05:06:15PM +0200, Christoph Hellwig wrote:
> > > > > On Tue, Jul 21, 2020 at 04:04:32PM +0100, Matthew Wilcox wrote:
> > > > > > I thought you were going to respin this with EREMCHG changed to ENOTBLK?
> > > > >
> > > > > Oh, true. I'll do that ASAP.
> > > >
> > > > Michael, could we add this to manpages?
> > >
> > > Umm, no. -ENOTBLK is internal - the file systems will retry using
> > > buffered I/O and the error shall never escape to userspace (or even the
> > > VFS for that matter).
> >
> > It's worth dropping a comment somewhere that ENOTBLK is the desired
> > "fall back to buffered" errcode, seeing as Dave and I missed that in
> > XFS...
>
> Sounds like a good idea, but what would a good place be?

In the comment that precedes iomap_dio_rw() for the iomap version,
and...

...ye $deity, the old direct-io.c file is a mess of wrappers. Uh... a
new comment preceding __blockdev_direct_IO? Or blockdev_direct_IO? Or
both?

Or I guess the direct_IO documentation in vfs.rst...?

``direct_IO``
called by the generic read/write routines to perform direct_IO -
that is IO requests which bypass the page cache and transfer
data directly between the storage and the application's address
space. This function can return -ENOTBLK to signal that it is
necessary to fallback to buffered IO. Note that
blockdev_direct_IO and variants can also return -ENOTBLK.

--D