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 b
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 po
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 othe
On Oct 9, 2006, at 3:23 PM, Phil Carns wrote:
Phil Carns wrote:
I started thinking about some more possible ideas, but I realized
after looking closer at the code that I don't actually see why
duplicates would occur in the first place with the algorithm that
is being used :) I apologize
On Oct 9, 2006, at 3:23 PM, Phil Carns wrote:
Phil Carns wrote:
I started thinking about some more possible ideas, but I realized
after looking closer at the code that I don't actually see why
duplicates would occur in the first place with the algorithm that
is being used :) I apologize
Phil Carns wrote:
I started thinking about some more possible ideas, but I realized
after looking closer at the code that I don't actually see why
duplicates would occur in the first place with the algorithm that is
being used :) I apologize if this has been discussed a few times
already, b
I started thinking about some more possible ideas, but I realized after
looking closer at the code that I don't actually see why duplicates
would occur in the first place with the algorithm that is being used :)
I apologize if this has been discussed a few times already, but could
we walk th
We've talked about having pvfs2-client pull out duplicates (or the
kernel module) in the cases where one of those chooses to break a
readdir into multiple operations, but we haven't spent much time
investigating where the replication is actually happening in order to
accomplish this.
Othe
Hi,
> Any other ideas?
The whole issue would be resolved naturally by using the filename as key
instead of the number. Also the pcache would not longer be necessary...
I know I'm really persistant on this one :)
Julian
___
Pvfs2-developers mailing list
On Oct 9, 2006, at 11:02 AM, Rob Ross wrote:
Hi Phil,
That's been around for a while (years). It's an artifact of ls
reading pieces of the directory list at a time, and the directory
list changing between directory reads.
We've talked about having pvfs2-client pull out duplicates (or the
Hi Phil,
That's been around for a while (years). It's an artifact of ls reading
pieces of the directory list at a time, and the directory list changing
between directory reads.
We've talked about having pvfs2-client pull out duplicates (or the
kernel module) in the cases where one of those c
This has got to caused by the way I did the caching of positions on
the server. I think it might make sense to replace that with code
that uses the component name as the position, instead of trying to
debug this problem. I feel like the caching is the inherent problem
that causes these
We are seeing a strange bug where if we list the contents of a directory
while files are being created in it, we sometimes get duplicates and/or
missing files in the output.
I can reproduce it on a single machine by running these two scripts at
the same time:
tester.sh:
-
13 matches
Mail list logo
