On 10 Mar 2022, at 15:15, Trond Myklebust wrote: > > The problem is really that 'ls' (or possibly glibc) is passing in a > pretty huge buffer to the getdents() system call. > > On my setup, that buffer appears to be 80K in size. So what happens is > that we get that first getdents() call, and so we fill the 80K buffer > with as many files as will fit. That can quickly run into several > thousand entries, if the filenames are relatively short. > > Then 'ls' goes through the contents and does a stat() (or a statx()) on > each entry, and so we record the statistics. However that means those > first several thousand entries are indeed going to use cached data, or > force GETATTR to go on the wire. We only start using forced readdirplus > on the second pass. > > Yes, I suppose we could limit getdents() to ignore the buffer size, and > just return fewer entries, however what's the "right" size in that > case? We can return fewer entries on the first call, so for the first pass the right size is NFS_READDIR_CACHE_MISS_THRESHOLD + 1. I sent a patch. > More to the point, how much pain are we going to accept before we give > up trying these assorted heuristics, and just define a readdirplus() > system call modelled on statx()? We cursed ourselves by creating the heuristic, and now we've had to maintain it and try to make everyone happy. The pain for us is when the behavior keeps changing after sites have come to rely on previous performance. I hope you can take a look at the patch. Ben
