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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
