Re: 'ls -lrt' performance issue on large dir while dir is being modified

[Trond Myklebust <trondmy@gmail.com>]

On Sat, 2020-01-18 at 10:03 -0800, Dai Ngo wrote:
> 
> I think this is the contention point: the spec did not explicitly
> mention anything regarding mixing of cookies from READDIR &
> READDIRPLUS.
> 
> However, as I mentioned, the current client implementation already
> mixing
> cookies between READDIRPLUS and READDIR, everytime the user does a
> simple
> 'ls' on a large directory, without invalidating any mapping.
> 
> Also, as Chuck mentioned, we're not aware of any server
> implementation
> that has problems with this mixing of cookies.
> 

OK I did a little time warp and went back to the original emails around
this behaviour:

https://linux-nfs.vger.kernel.narkive.com/O0Xhnqxe/readdir-vs-getattr


Part of the problem that needed solving at the time was that even when
the directory and its contents were not changing, people were still
needing to do reams of GETATTR calls in order to typically satisfy an
'ls -l' or even 'ls --color'. When we see that pattern, we want to
switch from using GETATTR on all these files to using READDIRPLUS.

The cache invalidation was introduced in order to force the NFS client
to do these READDIRPLUS calls so we avoid the GETATTRs.

So one optimisation we could definitely do is try to track the index of
the last page our descriptor accessed on readdir(), and truncate only
the remaining pages. That way we don't keep re-reading the beginning of
the directory.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com