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:

quoted

On Tue, Jul 21, 2020 at 05:16:16PM +0200, Christoph Hellwig wrote:

quoted

On Tue, Jul 21, 2020 at 04:14:37PM +0100, Matthew Wilcox wrote:

quoted

On Tue, Jul 21, 2020 at 05:06:15PM +0200, Christoph Hellwig wrote:

quoted

On Tue, Jul 21, 2020 at 04:04:32PM +0100, Matthew Wilcox wrote:

quoted

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