On Oct 12, 2006, at 12:45 PM, Pete Wyckoff wrote:
I could use some help tracking this down. Just updated from the
head into my local working copy and find that my standard tests
break.
On the server, in readdir, we end up in dbpf_keyval_iterate. It
calls dbpf_op_init_queued_or_immediate, which because we are using
immediate completion, does not grab a queued op structure, and does
not modify the passed-in pointer q_op_pp.
Unfortunately, the immediate completion path hasn't been tested
recently. Out of curiosity, have you always used it?
Then dbpf_keyval_iterate calls on down into dbpf_queue_or_service
with q_op_p == NULL. The first statement of that code does:
if( coll_p->immediate_completion &&
(DBPF_OP_IS_KEYVAL(op_p->type) || DBPF_OP_IS_DSPACE(op_p-
>type)))
but the op type is KEYVAL_ITERATE, so the condition fails. Is this
the problem?
Yeah I would bet.
Sam, I recall you replaced the ranges of op types with lots
of explicit equality comparisons for some reason. Did you leave
this one out on purpose? If not, does that indicate we should maybe
try to bug-proof these comparisons a bit? Maybe
#define KEYVAL 1<<6
#define DSPACE 1<<5
#define BSTREAM 1<<4
enum op_type {
KEYVAL_READ = KEYVAL | 1
KEYVAL_WRITE = KEYVAL | 2
KEYVAL_ITERATE = KEYVAL | 3
..
}
#define DBPF_OP_IS_KEYVAL(type) ((type) & KEYVAL)
I like this idea. Do you want to fix it? I can do it if you would
prefer.
-sam
Or tell me if I'm barking up the wrong tree.
-- Pete
_______________________________________________
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
