From: NeilBrown <neilb@suse.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: nfs@lists.sourceforge.net
Subject: [PATCH 001 of 2] Set meaningful value for fattr->time_start in readdirplus results.
Date: Tue, 6 Mar 2007 16:40:25 +1100 [thread overview]
Message-ID: <1070306054025.8345@suse.de> (raw)
In-Reply-To: 20070306163710.8128.patches@notabene
The 'fattr' structure filled in by nfs3_decode_direct does not get a
value for ->time_start set.
Thus if an entry is for an inode that we already have in cache,
when nfs_readdir_lookup calls nfs_fhget, it will call nfs_refresh_inode
and may update the inode with out-of-date information.
Directories are read a page at a time, so each page could have a
different timestamp that "should" be used to set the time_start for
the fattr for info in that page. However storing the timestamp per
page is awkward. (We could stick in the first 4 bytes and only read 4092
bytes, but that is a bigger code change than I was interested it).
This patch records the timestamp when the first page of a directory is
read and uses it to set the time_start for the fattr for each each
entry read from the directory. This if an inode has been updated more
recently than the directory was read, that information will not be
destroyed.
Signed-off-by: Neil Brown <neilb@suse.de>
### Diffstat output
./fs/nfs/dir.c | 4 ++++
1 file changed, 4 insertions(+)
diff .prev/fs/nfs/dir.c ./fs/nfs/dir.c
--- .prev/fs/nfs/dir.c 2007-03-06 15:35:44.000000000 +1100
+++ ./fs/nfs/dir.c 2007-03-06 15:46:46.000000000 +1100
@@ -153,6 +153,7 @@ typedef struct {
decode_dirent_t decode;
int plus;
int error;
+ unsigned long timestamp;
} nfs_readdir_descriptor_t;
/* Now we cache directories properly, by stuffing the dirent
@@ -202,6 +203,8 @@ int nfs_readdir_filler(nfs_readdir_descr
* Note: assumes we have exclusive access to this mapping either
* through inode->i_mutex or some other mechanism.
*/
+ if (page->index == 0)
+ desc->timestamp = timestamp;
if (page->index == 0 && invalidate_inode_pages2_range(inode->i_mapping, PAGE_CACHE_SIZE, -1) < 0) {
/* Should never happen */
nfs_zap_mapping(inode, inode->i_mapping);
@@ -1145,6 +1148,7 @@ static struct dentry *nfs_readdir_lookup
if (dentry == NULL)
return NULL;
dentry->d_op = NFS_PROTO(dir)->dentry_ops;
+ entry->fattr->time_start = desc->timestamp;
inode = nfs_fhget(dentry->d_sb, entry->fh, entry->fattr);
if (IS_ERR(inode)) {
dput(dentry);
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-03-06 5:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-06 5:40 [PATCH 000 of 2] A couple of possible nfs client patches NeilBrown
2007-03-06 5:40 ` NeilBrown [this message]
2007-04-14 22:13 ` [PATCH 001 of 2] Set meaningful value for fattr->time_start in readdirplus results Trond Myklebust
2007-04-15 23:35 ` Neil Brown
2007-04-16 15:23 ` Trond Myklebust
2007-03-06 5:40 ` [PATCH 002 of 2] Avoid flush-when-locking when interclient consistency not needed NeilBrown
2007-03-06 14:40 ` Trond Myklebust
2007-03-07 23:03 ` Neil Brown
2007-04-14 22:21 ` Trond Myklebust
2007-04-16 1:49 ` Chuck Lever
2007-04-16 14:12 ` Peter Staubach
2007-04-16 14:41 ` Trond Myklebust
2007-04-16 14:48 ` Peter Staubach
2007-03-06 14:57 ` [PATCH 000 of 2] A couple of possible nfs client patches Chuck Lever
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=1070306054025.8345@suse.de \
--to=neilb@suse.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.