[Pvfs2-developers] concurrent ls and rm

[Sam Lang]

On Sep 6, 2007, at 2:09 PM, Phil Carns wrote:

>
>> Hi Phil,
>> The trove layer caches the position -> name mapping for positions  
>> it  returns back to the client on a readdir.  The problem is  
>> probably  related to caching those entries, where the readdir for  
>> the rm is  iterating over the directory, and so inserting position  
>> -> name  entries into the cache, and then ls is coming along and  
>> replacing  those entries with its own, where the position is the  
>> same but the  name is further down in the directory (because rm  
>> has removed some of  them).  That's just a guess though.  You  
>> could see if disabling that  position cache helps fix the problem,  
>> disabling it will cause the  berkeley db iterate to walk through  
>> all the entries up to the  position though, so its going to be  
>> much slower.  The position cache  is in dbpf-keyval-pcache.c.
>> Probably the right long term solution is to return the name as  
>> the  position, instead of an int.
>
> I just replicated this using just 1000 files (each about 200 bytes)  
> in a single directory, again with one client doing an rm -rf and  
> another client doing an ls in the same directory.
>
> Unfortunately, it doesn't look like disabling the pcache made any  
> difference.  I first tried disabling it by adding a "return 0" at  
> the top of the PINT_dbpf_keyval_pcache_insert() function.  I also  
> tried modifying the dbpf_keyval_iterate_skip_to_position() function  
> to not call PINT_dbpf_keyval_pcache_lookup().
>
> Is there anything else I could do to make sure the pcache isn't  
> being used, or does this indicate that the problem is elsewhere?

Yeah, must be somewhere else.  Sorry for the red herring.  Hmm.   Is  
the file that's not getting deleted regular?  i.e.  Every file with  
positions in multiples of 32 or something.  If we had support for *  
in pvfs2-rm you could verify that its not the kernel module -- the  
position stuffing with iget4/5 in there has always seemed a bit  
crufty.  Otherwise, I would add gossip messages to the iterate code  
to see what positions were being given and returned.

-sam

>
> -Phil
>