[Pvfs2-developers] dbench and pvfs2_bufmap race
carns at mcs.anl.gov
Mon Jan 21 13:28:01 EST 2008
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# 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
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 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.
> 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.
More information about the Pvfs2-developers