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: Fri, 08 Apr 2005 21:23:24 -0400 [thread overview]
Message-ID: <1113009804.7459.9.camel@lindad> (raw)
In-Reply-To: <1112993686.7459.4.camel@lindad>
On Fri, 2005-04-08 at 16:54, Linda Dunaphant wrote:
>Do you think it would be better for nfs_refresh_inode() to check the mtime,
>perform the mtime update if needed, and not set the NFS_INO_INVALID_ATTR
>flag if the data_unstable flag is set? This is how nfs_update_inode()
>handles its mtime check.
Hi again Trond,
I updated my first patch to nfs_refresh_inode() to be similar to the way
nfs_update_inode() does the check and update of the mtime. nfs_refresh_inode()
now checks to see if the mtime changed, and if so, it does the update of
the mtime. It only sets NFS_INO_INVALID_ATTR if data_unstable is not set.
I temporarily added some printk's to selected functions to monitor some of
the functions called after the data write to the server occurs. With this
latest patch, the sequence that I see with the test program is now the
same as it was originally without any patch - except the mtime is has been
updated:
nfs3_xdr_writeargs
xdr_decode_fattr <--- new mtime from server
nfs_refresh_inode <--- updates mtime in inode
nfs_attribute_timeout
nfs_attribute_timeout
xdr_decode_fattr
nfs_refresh_inode
With the first patch I proposed this sequence was:
nfs3_xdr_writeargs
xdr_decode_fattr <--- new mtime from server
nfs_refresh_inode <--- NFS_INO_INVALID_ATTR set
xdr_decode_fattr
nfs_update_inode <--- updates mtime in inode
nfs_attribute_timeout
xdr_decode_fattr
Thank you for pointing out that there may be other consequences if the
NFS_INO_INVALID_ATTR is always set by nfs_refresh_inode() when the mtime
values are different. I believe this second patch fixes the original
problem without affecting any other behaviour.
Cheers,
Linda
diff -ura 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-08 19:23:44.151698674 -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;
+ }
+
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;
next prev parent reply other threads:[~2005-04-09 1:24 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 [this message]
2005-06-07 0:28 ` Linda Dunaphant
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=1113009804.7459.9.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 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.