On Wed, Aug 24, 2016 at 02:53:10PM +0000, Trond Myklebust wrote: > > > On Aug 24, 2016, at 10:40, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > On Wed, Aug 24, 2016 at 02:26:21PM +0000, Trond Myklebust wrote: > >> > >>> On Aug 24, 2016, at 10:20, <bfields@xxxxxxxxxxxx> wrote: > >>> I may be misunderstanding what the client's doing. If it's doing > >>> something like this: > >>> > >>> - return first hundred entries to user > >>> - throw out cache, restart readdir with cookie 0. > >>> - skip first hundred entries, return entries 101-200 to user. > >> > >> No. If the client has a cached cookie acting as the cursor, then we look for that cookie in the new stream. If we don’t find that cookie, then we do another readdir where that cookie acts as an argument, and use that to figure out where the stream now continues. > > > > Got it, thanks, so the struct file caches the real server side cookie > > even after you throw out the cached entries? OK, I guess I need to make > > another attempt at understanding the actual code, apologies. > > > > (Doesn't that mean that in the case your last position was a deleted > > file, you're probably going to have to read the entire directory to find > > out the cookie's not there? It seems so much more painful than starting > > off with the last cookie.) > > How do you cache the results of such a readdir? You'll have no reference point to figure out where you are in the stream. > Also, how do you convert that cookie into an offset that telldir() can use? No idea. But then, I don't really understand how we're going to do that even after reading the whole directory. Any telldir offsets that we've returned previously are in the future going to index into a completely new array, so they seem kind of meaningless. --b. -- 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
