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

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

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

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