Comment 67 for bug 2009325

Hi Du ChengEn,

Thanks for the clarification on test kernels. I am sad, I did not get to test your 2nd test kernel, as that would have revealed this issue immediately.

While the changes to fix LP: #2003053, went in there to fix a "bug" - it also created this major regression. But the bug fix just tries to get around the metadata inconsistencies, that has always been an issue with NFS (by design). Not a hard case IHMO, and also "rare" as pointed out in the original commit message.

I follow Jan here, that these changes should be reverted, as they create more problems than they tried to fix.

That does not stop anybody from working on an upstream solution, that would fit both purposes.

For whatever it is worth, this reproducer points out the pain point:

$ cd /nfsdir
$ touch myfiles.{1..1000}
$ md5sum myfiles.{1..1000} > /dev/null
$ sudo -u <myself> md5sum myfiles.{1..1000} > /dev/null

The latter 'md5sum' command produces 1000 GETATTR and 1000 ACCESS calls. The GEATTRs are there to ensure close-to-open consistency - fine. However, ACCESS calls should not be produced in this case, which shows the issue.

This is even more outspoken, if this is mounted using 'nocto' (as we do). The GETATTRs are gone (as they should). The ACCESS calls, however remain. This is where we get that huge increase in numbers.

With regards to potential increase in LOOKUPs - this is still to early. Caches are still not settled (lightly loaded system)

So, where do we go from here - create a new bug ? Give feedback on the linux-nfs mail list ?

I can see you already made a post to the mail list - I will be happy to be of assistance, if you see fit.