On Wed, Sep 30, 2020 at 3:02 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > On Wed, Sep 30, 2020 at 07:35:57AM +0300, Amir Goldstein wrote: > > I wonder out loud if this change of behavior you proposed is a good opportunity > > to introduce some of the verbs from SMB oplocks / NFS delegations into the > > FUSE protocol in order to allow finer grained control over per-file > > (and later also > > per-directory) caching behavior. > > May be. How will NFS delegation help with cache invalidation issue. I > mean if client B has the lease and modifying file, then client A will > still need to know when client B has modified the file and invalidate > its own caches. Right. So the way it would work in the mixed read-write workload is that the client tries to obtain a WRITE lease for the file. a) it could obtain the lease: it can do cached reads and writes without having to go to the server until the cache is flushed naturally or the lease is revoked. b) it can't obtain the lease: client will disable cache and let server manage coherency (cache=none basically). For a read-only workload the same happens but only a READ lease is requested. The nice thing is that multiple entities can have a READ lease on the file as long as it is not being modified. So this is best of both worlds, optimized for the non-contended case, but still consistent for the case when the file is being read/modified by more than one entity. Thanks, Miklos
