From: Steve Dickson <SteveD@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH] Reinstantiating stale inodes
Date: Mon, 03 May 2004 15:50:42 -0400 [thread overview]
Message-ID: <4096A292.8050109@RedHat.com> (raw)
In-Reply-To: <1083468517.3687.70.camel@lade.trondhjem.org>
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
Trond Myklebust wrote:
>I certainly would not expect any difference between the two when looking
>at the standard connectathon suite.
>
>
Nor did I... I kinda thought it would reduce traffic.... but over the
last few days,
I've tried a number of combinations of ctime and mtime to 1) fix the
estale problem and
2) not added more traffic... unfortunately with no success....
So I would like to propose a less intrusive patch what will simply zap
the directories caches when nfs_revalidate() sees an ESTALE.
This patch does not effect traffic and only the first dir entry is
failed with ESTALE
and finally subsequent ls will not fail with ESTALEs....
Comments?
SteveD.
[-- Attachment #2: linux-2.4.21-nfs-estale3.patch --]
[-- Type: text/plain, Size: 553 bytes --]
--- linux-2.4.21/fs/nfs/inode.c.org 2004-05-03 08:57:36.000000000 -0400
+++ linux-2.4.21/fs/nfs/inode.c 2004-05-03 15:03:57.000000000 -0400
@@ -958,8 +958,16 @@ nfs_wait_on_inode(struct inode *inode, i
int
nfs_revalidate(struct dentry *dentry)
{
+ int error;
struct inode *inode = dentry->d_inode;
- return nfs_revalidate_inode(NFS_SERVER(inode), inode);
+
+ error = nfs_revalidate_inode(NFS_SERVER(inode), inode);
+ if (error == -ESTALE) {
+ struct inode *dir = dentry->d_parent->d_inode;
+ nfs_zap_caches(dir);
+ }
+
+ return error;
}
/*
next prev parent reply other threads:[~2004-05-03 19:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-23 14:15 [PATCH] Reinstantiating stale inodes Steve Dickson
2004-04-23 14:33 ` Olaf Kirch
2004-04-23 15:50 ` Steve Dickson
2004-04-23 17:55 ` Olaf Kirch
2004-04-23 18:43 ` Steve Dickson
2004-04-23 18:50 ` Olaf Kirch
2004-04-23 20:07 ` Steve Dickson
2004-04-23 14:36 ` Trond Myklebust
2004-04-23 16:01 ` Steve Dickson
2004-04-23 16:21 ` Trond Myklebust
2004-04-23 17:21 ` Steve Dickson
2004-04-23 17:49 ` Trond Myklebust
2004-04-23 19:14 ` Steve Dickson
[not found] ` <40892DC0.1010001@redhat.com>
2004-04-23 16:04 ` Steve Dickson
2004-05-01 16:13 ` Steve Dickson
2004-05-01 19:25 ` Trond Myklebust
2004-05-01 23:57 ` Steve Dickson
2004-05-02 0:22 ` Trond Myklebust
2004-05-02 3:19 ` Steve Dickson
2004-05-02 3:28 ` Trond Myklebust
2004-05-03 19:50 ` Steve Dickson [this message]
2004-05-03 20:15 ` Trond Myklebust
2004-05-03 20:33 ` Steve Dickson
2004-05-03 21:27 ` Trond Myklebust
2004-05-04 19:05 ` Steve Dickson
2004-05-06 17:39 ` Steve Dickson
-- strict thread matches above, loose matches on Subject: below --
2004-04-23 14:48 Lever, Charles
2004-04-23 15:00 ` Trond Myklebust
2004-04-23 16:16 ` Steve Dickson
2004-04-23 15:08 ` Olaf Kirch
2004-04-23 15:17 Lever, Charles
2004-04-23 16:16 Lever, Charles
2004-04-23 16:27 ` Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4096A292.8050109@RedHat.com \
--to=steved@redhat.com \
--cc=nfs@lists.sourceforge.net \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox