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: Tue, 04 May 2004 15:05:27 -0400 [thread overview]
Message-ID: <4097E977.5020706@RedHat.com> (raw)
In-Reply-To: <1083619647.3896.126.camel@lade.trondhjem.org>
[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]
Trond Myklebust wrote:
>So the big question is: *why do you get all those extra writes*?
>
>
This appears to be a red herring... After a complete build in a
new tree that only had the ctime and zapping cache patches I started
to get more reasonable results... But it does appear that the ctime
patch does (consistently) cause more getattrs and lookups...
W/OUT any patches
Client rpc stats:
calls retrans authrefrsh
30052 16 0
Client nfs v3:
null getattr setattr lookup access readlink
0 0% 2288 7% 1199 3% 2561 8% 1171 3% 250 0%
read write create mkdir symlink mknod
3955 13% 11897 39% 893 2% 175 0% 250 0% 0 0%
remove rmdir rename link readdir readdirplus
1391 4% 175 0% 376 1% 250 0% 0 0% 1119 3%
fsstat fsinfo pathconf commit
1500 4% 1 0% 0 0% 601 1%
With CTIME patch
Client rpc stats:
calls retrans authrefrsh
30288 7 0
Client nfs v3:
null getattr setattr lookup access readlink
0 0% 2308 7% 1199 3% 2773 9% 1171 3% 250 0%
read write create mkdir symlink mknod
3954 13% 11899 39% 893 2% 175 0% 250 0% 0 0%
remove rmdir rename link readdir readdirplus
1391 4% 175 0% 380 1% 250 0% 0 0% 1119 3%
fsstat fsinfo pathconf commit
1500 4% 1 0% 0 0% 600 1%
>There weren't any extra changes to nfs_refresh_inode() that might cause
>the actual page cache invalidation to depend on the inode ctime (as
>opposed to just the lookup cache)?
>
>
No... there are some slight differences in __nfs_refresh_inode()... but
no smoking gun....
At this point I feel the numbers are close enough to declare victory.
The attached 2.4 patch *does* avoid ESTALEs when the server rsync -a the
mounted directory for a (very) small price... 1 to 2 percent increase in
traffic (in a particular kernel, running a particular test suite)
is not a bad price to pay to avoid ESTALEs.... imho...
What are the chances of this patch (or something similar) making
it into 2.4. tree?
SteveD.
[-- Attachment #2: linux-2.4-nfs-estale.patch --]
[-- Type: text/plain, Size: 3060 bytes --]
--- linux-2.4/fs/nfs/dir.c.orig 2003-11-11 16:55:40.000000000 -0500
+++ linux-2.4/fs/nfs/dir.c 2004-05-04 13:26:20.000000000 -0400
@@ -421,7 +421,7 @@ int nfs_check_verifier(struct inode *dir
return 1;
if (nfs_revalidate_inode(NFS_SERVER(dir), dir))
return 0;
- return time_after(dentry->d_time, NFS_MTIME_UPDATE(dir));
+ return time_after(dentry->d_time, NFS_CTIME_UPDATE(dir));
}
/*
--- linux-2.4/fs/nfs/inode.c.orig 2004-05-04 13:26:21.000000000 -0400
+++ linux-2.4/fs/nfs/inode.c 2004-05-04 13:28:20.000000000 -0400
@@ -821,8 +821,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;
}
/*
@@ -1054,16 +1062,16 @@ __nfs_refresh_inode(struct inode *inode,
if (nfs_have_writebacks(inode) && new_isize < inode->i_size)
new_isize = inode->i_size;
- NFS_CACHE_CTIME(inode) = fattr->ctime;
- inode->i_ctime = nfs_time_to_secs(fattr->ctime);
+ if (NFS_CACHE_CTIME(inode) != fattr->ctime) {
+ NFS_CACHE_CTIME(inode) = fattr->ctime;
+ inode->i_ctime = nfs_time_to_secs(fattr->ctime);
+ NFS_CTIME_UPDATE(inode) = jiffies;
+ }
inode->i_atime = new_atime;
- if (NFS_CACHE_MTIME(inode) != new_mtime) {
- NFS_MTIME_UPDATE(inode) = jiffies;
- NFS_CACHE_MTIME(inode) = new_mtime;
- inode->i_mtime = nfs_time_to_secs(new_mtime);
- }
+ NFS_CACHE_MTIME(inode) = new_mtime;
+ inode->i_mtime = nfs_time_to_secs(new_mtime);
NFS_CACHE_ISIZE(inode) = new_size;
inode->i_size = new_isize;
--- linux-2.4/include/linux/nfs_fs.h.orig 2004-05-04 13:26:23.000000000 -0400
+++ linux-2.4/include/linux/nfs_fs.h 2004-05-04 13:26:24.000000000 -0400
@@ -78,7 +78,7 @@ static inline struct nfs_inode_info *NFS
#define NFS_CONGESTED(inode) (RPC_CONGESTED(NFS_CLIENT(inode)))
#define NFS_COOKIEVERF(inode) ((inode)->u.nfs_i.cookieverf)
#define NFS_READTIME(inode) ((inode)->u.nfs_i.read_cache_jiffies)
-#define NFS_MTIME_UPDATE(inode) ((inode)->u.nfs_i.cache_mtime_jiffies)
+#define NFS_CTIME_UPDATE(inode) ((inode)->u.nfs_i.cache_ctime_jiffies)
#define NFS_CACHE_CTIME(inode) ((inode)->u.nfs_i.read_cache_ctime)
#define NFS_CACHE_MTIME(inode) ((inode)->u.nfs_i.read_cache_mtime)
#define NFS_CACHE_ISIZE(inode) ((inode)->u.nfs_i.read_cache_isize)
--- linux-2.4/include/linux/nfs_fs_i.h.orig 2004-05-04 13:26:24.000000000 -0400
+++ linux-2.4/include/linux/nfs_fs_i.h 2004-05-04 13:26:24.000000000 -0400
@@ -49,10 +49,10 @@ struct nfs_inode_info {
unsigned long attrtimeo_timestamp;
/*
- * Timestamp that dates the change made to read_cache_mtime.
+ * Timestamp that dates the change made to read_cache_ctime.
* This is of use for dentry revalidation
*/
- unsigned long cache_mtime_jiffies;
+ unsigned long cache_ctime_jiffies;
/*
* This is the cookie verifier used for NFSv3 readdir
next prev parent reply other threads:[~2004-05-04 19:05 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
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 [this message]
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=4097E977.5020706@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