[Cluster-devel] [PATCH 2/3] iomap: Only invalidate page cache pages on direct IO writes

2020-07-21 Thread Christoph Hellwig
From: Dave Chinner The historic requirement for XFS to invalidate cached pages on direct IO reads has been lost in the twisty pages of history - it was inherited from Irix, which implemented page cache invalidation on read as a method of working around problems synchronising page cache state

[Cluster-devel] iomap write invalidation v2

2020-07-21 Thread Christoph Hellwig
Changes since v1: - use -ENOTBLK for the direct to buffered I/O fallback everywhere - document the choice of -ENOTBLK better - update a comment in XFS

[Cluster-devel] [PATCH 3/3] iomap: fall back to buffered writes for invalidation failures

2020-07-21 Thread Christoph Hellwig
Failing to invalid the page cache means data in incoherent, which is a very bad state for the system. Always fall back to buffered I/O through the page cache if we can't invalidate mappings. Signed-off-by: Christoph Hellwig Acked-by: Dave Chinner Reviewed-by: Goldwyn Rodrigues ---

[Cluster-devel] [PATCH 1/3] xfs: use ENOTBLK for direct I/O to buffered I/O fallback

2020-07-21 Thread Christoph Hellwig
This is what the classic fs/direct-io.c implementation and thuse other file systems use. Signed-off-by: Christoph Hellwig --- fs/xfs/xfs_file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index 00db81eac80d6c..a6ef90457abf97

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Darrick J. Wong
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

Re: [Cluster-devel] [PATCH 3/3] iomap: fall back to buffered writes for invalidation failures

2020-07-21 Thread Darrick J. Wong
On Tue, Jul 21, 2020 at 08:31:57PM +0200, Christoph Hellwig wrote: > Failing to invalid the page cache means data in incoherent, which is > a very bad state for the system. Always fall back to buffered I/O > through the page cache if we can't invalidate mappings. > > Signed-off-by: Christoph

Re: [Cluster-devel] [PATCH 1/3] xfs: use ENOTBLK for direct I/O to buffered I/O fallback

2020-07-21 Thread Darrick J. Wong
On Tue, Jul 21, 2020 at 08:31:55PM +0200, Christoph Hellwig wrote: > This is what the classic fs/direct-io.c implementation and thuse other > file systems use. > > Signed-off-by: Christoph Hellwig Looks ok to me, Reviewed-by: Darrick J. Wong --D > --- > fs/xfs/xfs_file.c | 4 ++-- > 1 file

Re: [Cluster-devel] [PATCH 3/3] iomap: fall back to buffered writes for invalidation failures

2020-07-21 Thread Damien Le Moal
On 2020/07/22 3:32, Christoph Hellwig wrote: > Failing to invalid the page cache means data in incoherent, which is > a very bad state for the system. Always fall back to buffered I/O > through the page cache if we can't invalidate mappings. > > Signed-off-by: Christoph Hellwig > Acked-by: Dave

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Christoph Hellwig
On Mon, Jul 20, 2020 at 04:51:25PM -0500, Goldwyn Rodrigues wrote: > Hi Christoph, > > On 9:46 13/07, Christoph Hellwig wrote: > > Hi all, > > > > this series has two parts: the first one picks up Dave's patch to avoid > > invalidation entierly for reads, picked up deep down from the btrfs

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Matthew Wilcox
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? ---

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Darrick J. Wong
On Tue, Jul 21, 2020 at 04:53:13PM +0200, Christoph Hellwig wrote: > On Mon, Jul 20, 2020 at 04:51:25PM -0500, Goldwyn Rodrigues wrote: > > Hi Christoph, > > > > On 9:46 13/07, Christoph Hellwig wrote: > > > Hi all, > > > > > > this series has two parts: the first one picks up Dave's patch to

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Matthew Wilcox
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

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Christoph Hellwig
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,

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Christoph Hellwig
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

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Matthew Wilcox
On Tue, Jul 21, 2020 at 04:53:13PM +0200, Christoph Hellwig wrote: > On Mon, Jul 20, 2020 at 04:51:25PM -0500, Goldwyn Rodrigues wrote: > > Hi Christoph, > > > > On 9:46 13/07, Christoph Hellwig wrote: > > > Hi all, > > > > > > this series has two parts: the first one picks up Dave's patch to

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Christoph Hellwig
On Tue, Jul 21, 2020 at 04:04:32PM +0100, Matthew Wilcox wrote: > On Tue, Jul 21, 2020 at 04:53:13PM +0200, Christoph Hellwig wrote: > > On Mon, Jul 20, 2020 at 04:51:25PM -0500, Goldwyn Rodrigues wrote: > > > Hi Christoph, > > > > > > On 9:46 13/07, Christoph Hellwig wrote: > > > > Hi all, > >

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Christoph Hellwig
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.

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Matthew Wilcox
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

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Darrick J. Wong
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,

Re: [Cluster-devel] RFC: iomap write invalidation

2020-07-21 Thread Darrick J. Wong
On Tue, Jul 21, 2020 at 06:01:43PM +0200, Christoph Hellwig wrote: > On Tue, Jul 21, 2020 at 08:59:25AM -0700, Darrick J. Wong wrote: > > In the comment that precedes iomap_dio_rw() for the iomap version, > > maybe let's just do that.. > > > ``direct_IO`` > > called by the generic read/write