[Ocfs2-devel] [PATCH 1/1] Ocfs2: Stop tracking a negative dentry after dentry_iput().

[Ocfs2-devel] [PATCH 1/1] Ocfs2: Stop tracking a negative dentry after dentry_iput().

[Tristan Ye]

I suddenly hit the problem during 2.6.37-rc1 regression test, which was
introduced by commit '5e98d492406818e6a94c0ba54c61f59d40cefa4a'(Track
negative entries v3), following scenario reproduces the issue easily:

Node A			Node B
================	============
$touch 	testfile	
			$ls testfile
$rm -rf testfile
$touch 	testfile	
			$ls testfile
			ls: cannot access testfile: No such file or directory

This patch stops tracking the dentry which was negativated by a inode deletion,
so as to force the revaliation in next lookup, in case we'll touch the inode
again in the same node.

It didn't hurt the performance of multiple lookup for none-existed files anyway,
while regresses a bit in the first try after a file deletion.

Signed-off-by: Tristan Ye <tristan.ye@oracle.com>
---
 fs/ocfs2/dcache.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/fs/ocfs2/dcache.c b/fs/ocfs2/dcache.c
index edaded4..895532a 100644
--- a/fs/ocfs2/dcache.c
+++ b/fs/ocfs2/dcache.c
@@ -476,7 +476,6 @@ static void ocfs2_dentry_iput(struct dentry *dentry, struct inode *inode)
 
 out:
 	iput(inode);
-	ocfs2_dentry_attach_gen(dentry);
 }
 
 /*
-- 
1.5.5

[Ocfs2-devel] [PATCH 1/1] Ocfs2: Stop tracking a negative dentry after dentry_iput().

[Joel Becker]

On Mon, Nov 15, 2010 at 09:39:09PM +0800, Tristan Ye wrote:
> I suddenly hit the problem during 2.6.37-rc1 regression test, which was
> introduced by commit '5e98d492406818e6a94c0ba54c61f59d40cefa4a'(Track
> negative entries v3), following scenario reproduces the issue easily:
> 
> Node A			Node B
> ================	============
> $touch 	testfile	
> 			$ls testfile
> $rm -rf testfile
> $touch 	testfile	
> 			$ls testfile
> 			ls: cannot access testfile: No such file or directory
> 
> This patch stops tracking the dentry which was negativated by a inode deletion,
> so as to force the revaliation in next lookup, in case we'll touch the inode
> again in the same node.
> 
> It didn't hurt the performance of multiple lookup for none-existed files anyway,
> while regresses a bit in the first try after a file deletion.

	I'm going to take this fix for now, because it is clearing the
problem.  However, it looks like the original code _should_ work.  If we
have created a file, the directory's generation should have been
updated.  Thus, the pgen shouldn't match the generation set when the old
inode was deleted.  Right?

Joel


-- 

Life's Little Instruction Book #237

	"Seek out the good in people."

Joel Becker
Senior Development Manager
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] [PATCH 1/1] Ocfs2: Stop tracking a negative dentry after dentry_iput().

[Tristan Ye]

Joel Becker wrote:
> On Mon, Nov 15, 2010 at 09:39:09PM +0800, Tristan Ye wrote:
>> I suddenly hit the problem during 2.6.37-rc1 regression test, which was
>> introduced by commit '5e98d492406818e6a94c0ba54c61f59d40cefa4a'(Track
>> negative entries v3), following scenario reproduces the issue easily:
>>
>> Node A			Node B
>> ================	============
>> $touch 	testfile	
>> 			$ls testfile
>> $rm -rf testfile
>> $touch 	testfile	
>> 			$ls testfile
>> 			ls: cannot access testfile: No such file or directory
>>
>> This patch stops tracking the dentry which was negativated by a inode deletion,
>> so as to force the revaliation in next lookup, in case we'll touch the inode
>> again in the same node.
>>
>> It didn't hurt the performance of multiple lookup for none-existed files anyway,
>> while regresses a bit in the first try after a file deletion.
>
> 	I'm going to take this fix for now, because it is clearing the
> problem.  However, it looks like the original code _should_ work.  If we
> have created a file, the directory's generation should have been
> updated.  Thus, the pgen shouldn't match the generation set when the old
> inode was deleted.  Right?

Yep,

Original code did work of course, goldwyn's patch just tries to improve 
the performance by
reducing the possibility of calling revalidation for negative dentries 
on multiple lookups
on none-existed files.

If we created a file, the directory's generation only changes in the 
ocfs2_data_convert_worker,
which only happens when a node doing lock conversion, it means the pgen 
will not change if a node
creates the node without a dlmlock being converted.


Tristan.
>
> Joel
>
>

[Ocfs2-devel] [PATCH 1/1] Ocfs2: Stop tracking a negative dentry after dentry_iput().

[Tristan Ye]

Tristan Ye wrote:
> Joel Becker wrote:
>> On Mon, Nov 15, 2010 at 09:39:09PM +0800, Tristan Ye wrote:
>>> I suddenly hit the problem during 2.6.37-rc1 regression test, which was
>>> introduced by commit '5e98d492406818e6a94c0ba54c61f59d40cefa4a'(Track
>>> negative entries v3), following scenario reproduces the issue easily:
>>>
>>> Node A            Node B
>>> ================    ============
>>> $touch     testfile   
>>>             $ls testfile
>>> $rm -rf testfile
>>> $touch     testfile   
>>>             $ls testfile
>>>             ls: cannot access testfile: No such file or directory
>>>
>>> This patch stops tracking the dentry which was negativated by a 
>>> inode deletion,
>>> so as to force the revaliation in next lookup, in case we'll touch 
>>> the inode
>>> again in the same node.
>>>
>>> It didn't hurt the performance of multiple lookup for none-existed 
>>> files anyway,
>>> while regresses a bit in the first try after a file deletion.
>>
>>     I'm going to take this fix for now, because it is clearing the
>> problem.  However, it looks like the original code _should_ work.  If we
>> have created a file, the directory's generation should have been
>> updated.  Thus, the pgen shouldn't match the generation set when the old
>> inode was deleted.  Right?
I'm afraid it was not the case,

Say nodeA deleted the file(after Node B 'ls' it), Yes, now the 
generation number of
parent directory gets updated, and the newly-generated negative dentry 
inherits the
pgen, then we continue to do the creation(touch file) on nodeA without 
nodeB interleaves
the operation at all. in this case, pgen will not change since no 
dlmlock gets converted here,
reasonable?


Tristan.

>
> Yep,
>
> Original code did work of course, 

I may misunderstand you words a little bit here, I meant 'original code' 
is the codes before goldwyn's patch
being applied.

> goldwyn's patch just tries to improve the performance by
> reducing the possibility of calling revalidation for negative dentries 
> on multiple lookups
> on none-existed files.
>
> If we created a file, the directory's generation only changes in the 
> ocfs2_data_convert_worker,
> which only happens when a node doing lock conversion, it means the 
> pgen will not change if a node
> creates the node without a dlmlock being converted.
>
>
> Tristan.
>>
>> Joel
>>
>>
>

[Ocfs2-devel] [PATCH 1/1] Ocfs2: Stop tracking a negative dentry after dentry_iput().

[Joel Becker]

On Thu, Nov 18, 2010 at 10:08:04AM +0800, Tristan Ye wrote:
> Tristan Ye wrote:
> >>     I'm going to take this fix for now, because it is clearing the
> >> problem.  However, it looks like the original code _should_ work.  If we
> >> have created a file, the directory's generation should have been
> >> updated.  Thus, the pgen shouldn't match the generation set when the old
> >> inode was deleted.  Right?
> I'm afraid it was not the case,
> 
> Say nodeA deleted the file(after Node B 'ls' it), Yes, now the 
> generation number of
> parent directory gets updated, and the newly-generated negative dentry 
> inherits the
> pgen, then we continue to do the creation(touch file) on nodeA without 
> nodeB interleaves
> the operation at all. in this case, pgen will not change since no 
> dlmlock gets converted here,
> reasonable?

	Makes sense.  And since we're trying to avoid the cluster lock
with our validation, we can't take it to check.  Thanks.

Joel

-- 

"Anything that is too stupid to be spoken is sung."  
        - Voltaire

Joel Becker
Senior Development Manager
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

[Ocfs2-devel] [PATCH 1/1] Ocfs2: Stop tracking a negative dentry after dentry_iput().

[Joel Becker]

On Mon, Nov 15, 2010 at 09:39:09PM +0800, Tristan Ye wrote:
> I suddenly hit the problem during 2.6.37-rc1 regression test, which was
> introduced by commit '5e98d492406818e6a94c0ba54c61f59d40cefa4a'(Track
> negative entries v3), following scenario reproduces the issue easily:
> 
> Node A			Node B
> ================	============
> $touch 	testfile	
> 			$ls testfile
> $rm -rf testfile
> $touch 	testfile	
> 			$ls testfile
> 			ls: cannot access testfile: No such file or directory
> 
> This patch stops tracking the dentry which was negativated by a inode deletion,
> so as to force the revaliation in next lookup, in case we'll touch the inode
> again in the same node.
> 
> It didn't hurt the performance of multiple lookup for none-existed files anyway,
> while regresses a bit in the first try after a file deletion.
> 
> Signed-off-by: Tristan Ye <tristan.ye@oracle.com>

	This patch is now in the fixes branch of ocfs2.git.

Joel

-- 

"Only a life lived for others is a life worth while."
							-Albert Einstein  

Joel Becker
Senior Development Manager
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127