[Bugs] [Bug 1664934] glusterfs-fuse client not benefiting from page cache on read after write

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1664934



--- Comment #7 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Manoj Pillai from comment #5)
> (In reply to Raghavendra G from comment #4)
> > From preliminary tests I see two reasons for this:
> > 1. inode-invalidations triggered by md-cache
> > 2. Fuse auto invalidations
> 
> Trying with kernel NFS, another distributed fs solution. I see that cache is
> retained at the end of the write test, and both read-after-write and
> read-after-read are served from the page cache.
> 
> In principle, if kNFS can do it, FUSE should be able to do it. I think :D.

kNFS and FUSE have different invalidation policies.

* kNFS provides close-to-open consistency. To quote from their FAQ [1]

"Linux implements close-to-open cache consistency by comparing the results of a
GETATTR operation done just after the file is closed to the results of a
GETATTR operation done when the file is next opened. If the results are the
same, the client will assume its data cache is still valid; otherwise, the
cache is purged."

For the workload used in this bz, file is not changed between close and open.
Hence two values of stat fetched - at close and open - match and hence
page-cache is retained.

* FUSE auto-invalidation compares times of stats cached with the values got
from the underlying filesystem implementation at all codepaths where stat is
fetched. This means comparision happens in lookup, (f)stat, (f)setattr etc
codepaths. Since (f)stat, lookup can happen asynchronously and concurrently wrt
writes, they'll end up identifying delta between two values of stats resulting
in cache purge. Please note that the consistency offered by FUSE is stronger
than close-to-open consistency, which means it also provides close-to-open
consistency along with consistency in codepaths like lookup, fstat etc.

We have following options:

* disable auto-invalidations and use glusterfs custom designed invalidation
policy. The invalidation policy can be the same as NFS close-to-open
consistency or something more stronger.
* check whether the current form of auto-invalidation (though stricter)
provides any added benefits to close-to-open consistency which are useful. If
no, change FUSE auto-invalidation to close-to-open consistency.

[1] http://nfs.sourceforge.net/#faq_a8

-- 
You are receiving this mail because:
You are on the CC list for the bug.