[Pvfs2-developers] dbench and pvfs2_bufmap race

[Phil Carns]

Out of curiosity I ran ltp against pvfs trunk to see if it would find 
this problem.  I didn't find an exact match, but rename06 gives an 
interesting result.  Replicating on the command line looks like this:

   root@(none):/mnt/pvfs2/testdir# mkdir dir1
   root@(none):/mnt/pvfs2/testdir# mv dir1 dir1/dir2
   root@(none):/mnt/pvfs2/testdir# ls
   root@(none):/mnt/pvfs2/testdir#

That "mv" command is supposed to fail.  I'm not sure where dir1 went :)

-Phil

Phil Carns wrote:
> 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
>>>
>>
>