It looks like dbench is hanging on a rename of a file within a
subdirectory. I can replicate it outside of dbench like this:
root@(none):/mnt/pvfs2# pwd
/mnt/pvfs2
root@(none):/mnt/pvfs2# mkdir testdir
root@(none):/mnt/pvfs2# touch testdir/foo
root@(none):/mnt/pvfs2# mv testdir/foo testdir/bar
Everything works fine if I instead try to rename something with no
subdirectory:
root@(none):/mnt/pvfs2# touch foo
root@(none):/mnt/pvfs2# mv foo bar # so far so good
I don't think the "mkdir" and "touch" steps are relevant other than just
for an example. I think get the same hang if the file and subdir
already exist when pvfs is mounted.
-Phil
Phil Carns wrote:
Whoops - it looks like the pvfs2-client-core crash didn't really have
much to do w/ dbench. That was a red herring (a system/compile problem
on my end was what really triggered that), but I think the fixes to
address the bufmap race conditions ended up being a good thing anyway :)
Anyway, I can't vouch for the current state of dbench with pvfs2 trunk;
I think it probably still hangs the client machine just as before.
-Phil
Robert Latham wrote:
On Thu, Jan 17, 2008 at 06:37:52PM -0600, Phil Carns wrote:
1) dbench somehow kills pvfs2-client-core (not sure why yet)
Hi Phil
Thanks for taking a look at the dbench failures.
I confirmed yesterday that revision 1.32 of
src/kernel/linux-2.6/dcache.c is the last revision to pass dbench.
Sam already knows that's a suspect area. I'm just saying by starting
with HEAD and reverting that one file to 1.32 dbench (and all the
other nightlies) pass.
Why do subsequent revisions make pvfs2-client-core blow up? no idea.
It's no small change, and related if I remember correctly to Sam and
Kevin debugging some BGP issues, so reverting it doesn't seem like the
right thing to do.
==rob
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
