On 3/19/24 17:40, Miklos Szeredi wrote: > 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! Fyi, we are actually planning to extend fuse notifications from inode to page ranges. Thanks, Bernd
