On Tue, 19 Mar 2024 at 17:13, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, 19 Mar 2024 at 15:15, David Howells <dhowells@xxxxxxxxxx> wrote: > > > What particular usage case of invalidate_inode_pages2() are you thinking of? > > FUSE_NOTIFY_INVAL_INODE will trigger invalidate_inode_pages2_range() > to clean up the cache. > > The server is free to discard writes resulting from this invalidation > and delay reads in the region until the invalidation finishes. This > would no longer work with your change, since the mapping could > silently be reinstated between the writeback and the removal from the > cache due to the page being unlocked/relocked. This would also matter if a distributed filesystem wanted to implement coherence even if there are mmaps. I.e. a client could get exclusive access to a region by issuing FUSE_NOTIFY_INVAL_INODE on all other clients and blocking reads. With your change this would fail. Again, this is purely theoretical, and without a way to differentiate between the read-only and write cases it has limited usefulness. Adding leases to fuse (which I plan to do) would make this much more useful. Thanks, Miklos
