On Dec 6, 2022, at 8:21 AM, Benjamin Coddington [off-list ref] wrote:

On 5 Dec 2022, at 21:18, Theodor Mittermair wrote:

quoted

Hello,

Hi Theodor,

.. snip ..

quoted

From what i gathered around the internet and understood, there seem to be
heuristics involved when the client decides what operations to transmit to
the server.  Also, the timed-out cache seems to be creating what some
called a "getattr storm", which i understand in theory.

When `du` gathers information, it does so by switching between two syscalls:
getdents() and stat() (or some equivalents).  The getdents() syscall causes
the NFS client to perform either READDIR or READDIRPLUS - the choice of
which is governed by a heuristic.  The heuristic can only intelligently
determine which readdir operation to use based on whether the program is
performing this pattern of getdents(), stat(), stat(), stat(), getdents(),
stat(), stat(), stat().  The way it can tell is by checking if each inode's
attributes have been cached, so the cache timeouts end up coming into play.

quoted

But why does the first request manage to be smarter about it, since it
gathers the same information about the exact same files?

It's not smarter, it just optimistically uses READDIRPLUS on the very first
call of getdents() for a directory, but can only do so if the directory's
dentries have not yet been cached.  If they /are/ cached, but each dentry's
individual attributes have timed out, then the client must send an
individual GETATTR for each entry.

What is happening for you is that your attribute caches for each inode are
timing out, but the overall directory's dentry list is not changing.
There's no need to send /any/ readdir operations - so the heuristic doesn't
send READDIRPLUS and you end up with one full pile of getdents() results of
individual GETATTRs for every entry.

Are those GETATTRs emitted one at a time sequentially, or concurrently?

--
Chuck Lever