Re: recent NFS problems?

[Trond Myklebust <Trond.Myklebust@netapp.com>]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Sat, 2005-11-05 at 01:28 -0500, Jeff Garzik wrote:
> This is a bit weird.  Running 2.6.14-g6037d6bb (libata-dev.git branch 
> 'upstream') on both client and server.  Its latest Linux 
> (7015faa7df829876a0f931cd18aa6d7c24a1b581) plus one libata patch.  All 
> NFSv4 kernel options are enabled, on both client and server.
> 
> On Host A, I mirror a local directory /garz/nsmail to an NFS directory 
> Host_B:/g/g/nsmail via rsync+ssh.  Host A also NFS mounts Host_B:/g 
> locally.  mount on Host A says
> 
> 	host_b:/g on /g type nfs (rw,tcp,intr,posix,addr=10.10.10.1)
> 
> Seeing some directory weirdness, where wildcard matches fail 
> (NFS-related dcache bugs?) but direct accesses succeed:
> 
> [jgarzik@host_a~]$ ssh host_b "ls -d /g/g/nsmail/Trash.sbd/*11*"
> /g/g/nsmail/Trash.sbd/Sent.20051105
> /g/g/nsmail/Trash.sbd/Sent.20051105.msf
> /g/g/nsmail/Trash.sbd/Sent.20051105.sbd
> /g/g/nsmail/Trash.sbd/Trash.20051105
> /g/g/nsmail/Trash.sbd/Trash.20051105.msf
> /g/g/nsmail/Trash.sbd/Trash.20051105.sbd
> 
> [jgarzik@host_a ~]$ ls -d /g/g/nsmail/Trash.sbd/*11*
> ls: /g/g/nsmail/Trash.sbd/*11*: No such file or directory
> 
> [jgarzik@host_a ~]$ ls -l /g/g/nsmail/Trash.sbd/Trash.20051105
> -rw-rw-r--  1 jgarzik jgarzik 67484129 Nov  5 00:02 
> /g/g/nsmail/Trash.sbd/Trash.20051105
> 
> [jgarzik@host_a~]$ wc -l /g/g/nsmail/Trash.sbd/Trash.20051105
> 1739088 /g/g/nsmail/Trash.sbd/Trash.20051105

Hmm... Does reverting the attached patch help?

Cheers,
  Trond


[-- Attachment #2: linux-2.6.14-77-remove_lookup_parent_reval.dif --]
[-- Type: text/plain, Size: 1508 bytes --]

Author: Chuck Lever <cel@netapp.com>
Date: Tue, 25 Oct 2005 11:48:36 -0400
NFS: nfs_lookup doesn't need to revalidate the parent directory's inode

 nfs_lookup() used to consult a lookup cache before trying an actual wire
 lookup operation.  The lookup cache would be invalid, of course, if the
 parent directory's mtime had changed, so nfs_lookup performed an inode
 revalidation on the parent.

 Since nfs_lookup() doesn't use a cache anymore, the revalidation is no
 longer necessary.  There are cases where it will generate a lot of
 unnecessary GETATTR traffic.

 See http://bugzilla.linux-nfs.org/show_bug.cgi?id=9

 Test-plan:
 Use lndir and "rm -rf" and watch for excess GETATTR traffic or application
 level errors.

 Signed-off-by: Chuck Lever <cel@netapp.com>
 Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
 fs/nfs/dir.c |    6 ------
 1 files changed, 6 deletions(-)

Index: linux-2.6/fs/nfs/dir.c
===================================================================
--- linux-2.6.orig/fs/nfs/dir.c
+++ linux-2.6/fs/nfs/dir.c
@@ -853,12 +853,6 @@ static struct dentry *nfs_lookup(struct 
 	dentry->d_op = NFS_PROTO(dir)->dentry_ops;
 
 	lock_kernel();
-	/* Revalidate parent directory attribute cache */
-	error = nfs_revalidate_inode(NFS_SERVER(dir), dir);
-	if (error < 0) {
-		res = ERR_PTR(error);
-		goto out_unlock;
-	}
 
 	/* If we're doing an exclusive create, optimize away the lookup */
 	if (nfs_is_exclusive_create(dir, nd))