* Re: recent NFS problems?
2005-11-05 6:28 recent NFS problems? Jeff Garzik
@ 2005-11-05 15:50 ` Trond Myklebust
0 siblings, 0 replies; 2+ messages in thread
From: Trond Myklebust @ 2005-11-05 15:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, nfs
[-- 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))
^ permalink raw reply [flat|nested] 2+ messages in thread