[Pvfs2-developers] readdir count and token position

[Phil Carns]

FYI, I reduced the limit (in the kernel only, not pvfs2-ls) down to 96 
for the time being in cvs trunk.  This avoids the token rewind problem 
triggered by bonnie++, but hopefully still keeps some of the ls speed 
improvement.

-Phil

Phil Carns wrote:
> We recently applied a patch from Bart Taylor to increase the default 
> directory entry count from 32 to up to 512 in trunk:
> 
> http://www.beowulf-underground.org/pipermail/pvfs2-developers/2008-September/004147.html 
> 
> 
> Unfortunately, it looks like this has brought back an old problem of how 
> to deal with directory entries being deleted between readdir iterations.
> 
> The problem can be triggered by bonnie++, and looks something like this 
> (I'm making up numbers to illustrate):
> 
> - a directory has 1000 entries
> - client requests the first 512 entries
> - server returns 512 entries
>   - server sets readdir token to 513
>   - server stores token 513 in the pcache
> - client receives response
>   - client is only able to fit 100 entries in its getdents buffer
>   - client sets readdir token (directory position) to 101
> - client deletes first 100 entries
> - client requests the next 512 entries at token 101
> - server looks for token 101 in its pcache
>   - pcache misses (because it cached 513, not 101)
>   - server falls back to stepping through directory to 101st entry
>   - server returns 512 entries, starting at current 101st entry
> 
> The problem here is that 100 entries get skipped because the server 
> picks up at a position relative to the current state of the directory 
> (after deletes) rather than the original state of the directory (which 
> is what the client really wants).
> 
> Previously the pcache kept this from happening, because it associates a 
> db cursor with the last token position.  The problem now is that the 
> large dirent count can cause the client to have to rewind the position 
> so that it doesn't pick up where it left off.  Even then, rewinding is 
> ok unless you are also deleting entries in the directory between 
> iterations.
> 
> Is there any clever solution to this, or do we just need to back the 
> dirent count in the kernel code down to something less aggressive to 
> avoid the problem?
> 
> -Phil
> 
> 
> 
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers