Re: I can't get no readdir satisfaction

[bfields@fieldses.org (J. Bruce Fields)]

On Tue, Aug 23, 2016 at 11:09:37AM -0400, Benjamin Coddington 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.

Apologies, I don't understand the client's readdir implementation.  So
it really zeroes out the cookie every time it invalidates the directory
cache?

I also seem to remember it makes up its own cookies to return to users
instead of returning the server's.  Is the cookie invalidation a
consequence of that?  I don't think it should have to be.  And as long
as these two things (cache and cookie validity) are tied together, I
can't see how we're going to guarantee readdir progress.

--b.

> 
> 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?
> 
> Ben
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html