public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linda Dunaphant <linda.dunaphant@ccur.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtime attribute is not being updated on client
Date: Mon, 06 Jun 2005 20:28:27 -0400	[thread overview]
Message-ID: <1118104107.13894.20.camel@lindad> (raw)
In-Reply-To: <1113009804.7459.9.camel@lindad>

Trond,

After running for awhile with the mtime related changes that I made to
nfs_refresh_inode() on 4/8/05, I noticed that I would sometimes see
stale file data on an an NFS client if the file had been updated but
it's new filesize was the same as the old filesize. The clients were
seeing the correct mtime for the file, but the data was stale.

In my previous change for mtime in nfs_refresh_inode(), the inode was
being marked invalid, but the data was not. In the following patch, if
the mtime is updated and the data_unstable flag is not true, the inode
and the data will both be marked invalid. These changes solved the
original mtime issue as well as the stale data problem that I was
seeing.

Linda

The following patch is for 2.6.12-rc2:

diff -Nrau base/fs/nfs/inode.c new/fs/nfs/inode.c
--- base/fs/nfs/inode.c	2005-04-07 16:04:40.000000000 -0400
+++ new/fs/nfs/inode.c	2005-04-18 21:48:28.000000000 -0400
@@ -1176,9 +1176,17 @@
 	}
 
 	/* Verify a few of the more important attributes */
+	if (!timespec_equal(&inode->i_mtime, &fattr->mtime)) {
+		memcpy(&inode->i_mtime, &fattr->mtime, sizeof(inode->i_mtime));
+#ifdef NFS_DEBUG_VERBOSE
+		printk(KERN_DEBUG "NFS: mtime change on %s/%ld\n", inode->i_sb->s_id, inode->i_ino);
+#endif
+		if (!data_unstable)
+			nfsi->flags |= NFS_INO_INVALID_ATTR|NFS_INO_INVALID_DATA;
+	}
+
 	if (!data_unstable) {
-		if (!timespec_equal(&inode->i_mtime, &fattr->mtime)
-				|| cur_size != new_isize)
+		if (cur_size != new_isize)
 			nfsi->flags |= NFS_INO_INVALID_ATTR;
 	} else if (S_ISREG(inode->i_mode) && new_isize > cur_size)
 			nfsi->flags |= NFS_INO_INVALID_ATTR;



  reply	other threads:[~2005-06-07  0:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-08  0:52 [PATCH] mtime attribute is not being updated on client Linda Dunaphant
2005-04-08 13:11 ` Trond Myklebust
2005-04-08 20:54   ` Linda Dunaphant
2005-04-09  1:23     ` Linda Dunaphant
2005-06-07  0:28       ` Linda Dunaphant [this message]
2005-06-07  2:29         ` NFS: NFS3 lookup fails if creating a file with O_EXCL & multiple mountpoints in pathname Linda Dunaphant
2005-06-07  3:01           ` Trond Myklebust
2005-06-07 13:41           ` Trond Myklebust
2005-06-07 22:10             ` Linda Dunaphant

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=1118104107.13894.20.camel@lindad \
    --to=linda.dunaphant@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    --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