Re: I can't get no readdir satisfaction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Aug 23, 2016, at 11:09, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote:
> 
> Hi linux-nfs,
> 
> 311324ad1713 ("NFS: Be more aggressive in using readdirplus for 'ls -l'
> situations") changed when nfs_readdir() decides to revalidate the
> directory's mapping, which contains all the entries.  In addition to just
> checking if the attribute cache has expired, it includes a check to see if
> NFS_INO_INVALID_DATA is set on the directory.
> 
> Well, customers that have directories with very many dentries and that same
> directory's attributes are frequently updated are now grouchy that `ls -l`
> takes so long since any update of the directory causes the mapping to be
> invalidated and we have to start over filling the directory's mapping.
> 
> I actually haven't put real hard thought into it yet (because often for me
> that just wastes a lot of time), so I am doing the lazy thing by asking this
> question:
> 
> Can we go back to just the using the attribute cache timeout, or should we
> get all heuristical about readdir?
> 

We are all heuristical at this point. How are the heuristics failing?

The original problem those heuristics were designed to solve was that all the stat() calls took forever to complete, since they are all synchronous; Tigran showed some very convincing numbers for a large directory where the difference in performance was an order of magnitude improved by using readdirplus instead of readdir…

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux