Thanks guys! This patch does fix the problem.
David suspected that retry logic too, but I thought it had been removed
back when the pcache changes were made :)
I don't think there will be any significant skew with deleted files.
Each readdir request on the server side (regardless of token position)
is only going to show entries that exist at the time of the readdir
request. The pcache does cache the position, but it skips ahead to the
next appropriate entry in sorted order if the cached entry is deleted.
The request scheduler should prevent readdir and rmdirent from running
simultaneously on a directory.
Someone could of course delete one of the 32 entries in a given readdir
request in between when the server retrieves them and when they are
displayed on the client, but that is a user/application problem if
anyone is hoping for different behavior.
-Phil
Murali Vilayannur wrote:
Hi,
Phil, attached patch fixes the behavior that you described.
Basically the problem is exactly what Sam had described.
There is no point retrying a readdir of 32 entries when the actual ls
command may have issued previous readdir's that are not retried.
That said, I am sure this will cause other problems such as deleted
files showing up until the entire listing completes ..
thanks,
Murali
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
