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
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
