On 16:13 28/05, Filipe Manana wrote: > On Tue, May 26, 2020 at 5:47 PM Goldwyn Rodrigues <rgoldwyn@xxxxxxx> wrote: > > > > On 15:03 26/05, Johannes Thumshirn wrote: > > > Just as a heads up, this one gives me lot's of Page cache invalidation > > > failure prints from dio_warn_stale_pagecache() on btrfs/004 with > > > current misc-next: > > > > > <snip> > > > > > [ 23.696400] Page cache invalidation failure on direct I/O. Possible data corruption due to collision with buffered I/O! > > > [ 23.698115] File: /mnt/scratch/bgnoise/p0/f0 PID: 6562 Comm: fsstress > > > > > > I have no idea yet why but I'm investigating. > > > > This is caused because we are trying to release a page when the extent > > has locked the page and release page returns false. > > By "we" you mean what exaclty, a direct IO read, a direct IO write? > > And who locked the extent range before? This is usually locked by a previous buffered write or read. > > That seems alarming to me, specially if it's a direct IO write failing > to invalidate the page cache, since a subsequent buffered read could > get stale data (what's in the page cache), and not what the direct IO > write wrote. > > Can you elaborate more on all those details? The origin of the message is when iomap_dio_rw() tries to invalidate the inode pages, but fails and calls dio_warn_stale_pagecache(). In the vanilla code, generic_file_direct_write() aborts direct writes and returns 0 so that it may fallback to buffered I/O. Perhaps this should be changed in iomap_dio_rw() as well. I will write a patch to accomodate that. -- Goldwyn
