On Mon, 2022-02-21 at 16:10 -0500, Benjamin Coddington wrote: > On 21 Feb 2022, at 15:55, Trond Myklebust wrote: > > > > We will always need the ability to cut over to uncached readdir. > > Yes. > > > If the cookie is no longer returned by the server because one or > > more > > files were deleted then we need to resolve the situation somehow > > (IOW: > > the 'rm *' case). The new algorithm _does_ improve performance on > > those > > situations, because it no longer requires us to read the entire > > directory before switching over: we try 5 times, then fail over. > > Yes, using per-page validation doesn't remove the need for uncached > readdir. > It does allow a reader to simply resume filling the cache where it > left > off. There's no need to try 5 times and fail over. And there's no > need to > make a trade-off and make the situation worse in certain scenarios. > > I thought I'd point that out and make an offer to re-submit it. Any > interest? > As I recall, I had concerns about that approach. Can you explain again how it will work? A few of the concerns I have revolve around telldir()/seekdir(). If the platform is 32-bit, then we cannot use cookies as the telldir() output, and so our only option is to use offsets into the page cache (this is why this patch carves out an exception if desc->dir_cookie == 0). How would that work with you scheme? Even in the 64-bit case where are able to use cookies for telldir()/seekdir(), how do we determine an appropriate page index after a seekdir()? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
