I've committed the patch to CVS.
Thanks Murali!
-sam
On Oct 10, 2006, at 9:07 AM, Phil Carns wrote:
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
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
