lkml.org 
[lkml]   [2005]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: recent NFS problems?
From
Date
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

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))
\
 
 \ /
  Last update: 2005-11-05 17:11    [W:0.036 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site