Access cache and lookupcache=pos

Access cache and lookupcache=pos

[Geert Jansen]

Hi,

some of our customers run applications that require the lookupcache=pos
mount option. One example of such an application is Gitlab [1]. Recently we
profiled a Gitlab workload and noticed that 38% of compound operations and
27% of EFS server time were spent on an ACCESS compound (SEQUENCE, PUTFH,
ACCESS, GETATTR) that we weren't sure is necessary.

To reproduce:

1. Mount an NFS file system with -o lookupcache=pos.
2. $ mkdir /mnt/a
3. $ for i in `seq 1 10`; do ls /mnt/a/nonex.txt; done

There are two compounds that are emitted for every iteration in step 3:

1. SEQUENCE, PUTFH, ACCESS, GETATTR
2. SEQUENCE, PUTFH, LOOKUP, GETFH, GETATTR

In the first compound, ACCESS has FH=</mnt/a> and access=0x1f. The result is
NFS4_OK with supported=0x1f and access=1f. In the second compound, LOOKUP
has FH=</mnt/a> and objname="nonex.txt". The result is NFS4ERR_NOENT.

If I understand lookupcache=pos correctly, it causes the result of LOOKUP
not to be cached because of the ENOENT, which is what's happening. Is there
a reason that the succesful ACCESS is not cached in the parent directory's
access_cache? Caching it would reduce the runtime of this application by
about 27% which would be a nice speedup.

[1] https://docs.gitlab.com/ee/administration/nfs.html