[Ocfs2-devel] [PATCH] Track negative dentries

[Sunil Mushran]

Are you referring to the dentry lock? We encode the parent inode in  
the lock. But the difference is that a dentry having that lock cannot  
be a negative dentry.

On Jun 21, 2010, at 10:22 PM, Wengang Wang <wen.gang.wang at oracle.com>  
wrote:

> On 10-06-21 20:36, Joel Becker wrote:
>> On Tue, Jun 22, 2010 at 11:23:33AM +0800, Wengang Wang wrote:
>>> Actually I meant two dentries in the two run of 'ls -l'.
>>> At the first run, a dentry, dentry A, is created. Because fileA  
>>> doesn't exist,
>>> dentry->d_inode is NULL. Then a do_revalidate() is run,
>>> ocfs2_dentry_revalidate() returns "not valid" since d_inode is NULL.
>>> Thus the dentry A is unhashed from cache by d_invalidate().
>>> At the second run of 'ls -l', since dentry A is unhashed, there is  
>>> no dentry for
>>> fileA exist in dentry hash, a new dentry, dentry B, is created.  
>>> The new dentry B
>>> don't have any info about parent ino.
>>>
>>> I found that when testing my patch for the "track negative  
>>> dentries".
>>> Maybe I misunderstand something?
>>
>>    When that dentry gets linked into the tree, it will point to its
>> d_parent.  So the parent inode is dentryB->d_parent->d_inode.
>
> Yes Joel, I know that link.
> I meant there is no parent inode number stored on on dentryB it's  
> self,
> thus no way to compare it with dentryB->d_parent->d_inode.
> We set the parent inode number info to dentryA(somewhere in d_fsdata).
> But it's lost at the second 'ls -l' because dentryB is got instead  
> of dentryA.
>
> regards,
> wengang.