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
