[Pvfs2-developers] dbench and pvfs2_bufmap race

[Phil Carns]

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
>>
>