Comment 11 for bug 2015827

Sorry for the confusion. Thank you for clarifying. Here is our test:

We installed linux-5.4.0-156.173 (focal) from -proposed and tested it out with good results. Ran test script on a mounted nfs share. Silly little test (test.sh seen below):

#!/bin/bash

nfsstat -l | grep access
touch myfiles.{1..1000}
md5sum myfiles.{1..1000} > /dev/null
sudo -u $(whoami) md5sum myfiles.{1..1000} > /dev/null
nfsstat -l | grep access

Kernel info:

# dpkg -l linux-image-generic | tail -1
ii linux-image-generic 5.4.0.156.152 amd64 Generic Linux kernel image

$ uname -rv
5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023

Test with the change in place:

$ cat /sys/module/nfs/parameters/nfs_fasc
N
$ ./test.sh
nfs v3 client access: 45
nfs v3 client access: 1045
$ ./test.sh
nfs v3 client access: 1045
nfs v3 client access: 1045
$ ./test.sh
nfs v3 client access: 1045
nfs v3 client access: 1045
$ ./test.sh
nfs v3 client access: 1045
nfs v3 client access: 1045

Unmount, reload the nfs module with nfs_fasc=Y, and re-test:

# umount /mnt/nfs-share
# rmmod nfsv3
# rmmod nfs
# modprobe nfs nfs_fasc=Y
$ cat /sys/module/nfs/parameters/nfs_fasc
Y
$ ./test.sh
nfs v3 client access: 28
nfs v3 client access: 2029
$ ./test.sh
nfs v3 client access: 2029
nfs v3 client access: 3030
$ ./test.sh
nfs v3 client access: 3030
nfs v3 client access: 4031
$ ./test.sh
nfs v3 client access: 4031
nfs v3 client access: 5032

Conclusion: with the nfs_fasc parameter change defaulting to off, linux-5.4.0-156.173 returns to the old behavior and NFS ACCESS calls are not made on every new session access. After loading the nfs module with the nfs_fasc parameter on, the new session NFS ACCESS call behavior resumes.

The nfs_fasc parameter functions as expected. This patch appears to revert to the old level of NFS ACCESS calls that we expected.