On Tue, Jul 21, 2020 at 04:52:01PM +0100, Matthew Wilcox wrote: > On Tue, Jul 21, 2020 at 05:42:40PM +0200, Christoph Hellwig wrote: > > On Tue, Jul 21, 2020 at 04:31:36PM +0100, Matthew Wilcox wrote: > > > > 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). > > > > > > Ah, I made the mistake of believing the comments that I could see in > > > your patch instead of reading the code. > > > > > > Can I suggest deleting this comment: > > > > > > /* > > > * No fallback to buffered IO on errors for XFS, direct IO will either > > > * complete fully or fail. > > > */ > > > > > > and rewording this one: > > > > > > /* > > > * Allow a directio write to fall back to a buffered > > > * write *only* in the case that we're doing a reflink > > > * CoW. In all other directio scenarios we do not > > > * allow an operation to fall back to buffered mode. > > > */ > > > > > > as part of your revised patchset? > > > > That isn't actually true. In current mainline we only fallback on > > reflink RMW cases, but with this series we also fall back for > > invalidation failures. > > ... that's why I'm suggesting that you delete the first one and rewrite > the second one. Because they aren't true. /* * We allow only three outcomes of a directio: (1) it succeeds * completely; (2) it fails with a negative error code; or (3) it * returns -ENOTBLK to signal that we should fall back to buffered IO. * * The third scenario should only happen if iomap refuses to perform the * direct IO, or the direct write request requires CoW but is not aligned * to the filesystem block size. */ ? --D
