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 16:54:47 -0400 [thread overview]
Message-ID: <1112993686.7459.4.camel@lindad> (raw)
In-Reply-To: <1112965872.15565.34.camel@lade.trondhjem.org>
On Fri, 2005-04-08 at 09:11, Trond Myklebust wrote:
> I'm a bit unclear as to what your end-goal is here. Is it basically to
>ensure that fstat() always return the correct value for the mtime?
>
> The reason I ask is that I think your change is likely to have nasty
>consequences for the general performance in a lot of other syscalls that
>use nfs_revalidate_inode(). I would expect a particularly nasty hit in
>the of the write() syscalls themselves, and they really shouldn't have
>to worry about the value of mtime in the close-to-open cache consistency
>model.
>I therefore think we should look for a more fine-grained solution that
>addresses more precisely the issues you see.
>
>Cheers,
> Trond
Hi Trond,
The goal wasn't to ensure that fstat() always return the correct value for
mtime. The goal is to update the mtime within the bounds of the min and max
attribute cache timeouts, which was not happening before if the test ran
for more than a minute.
nfs_refresh_inode() was already being called after every write to the server
and fattr->mtime was already set to the server's updated mtime value. However,
it didn't check for an updated mtime value if data_unstable was set. Since
nfs_refresh_inode() always resets the attribute timer (even when it skipped
the mtime check), and the calls to it occurred more frequently than the
attribute timer could expire, nfs_update_inode() was never being called
again to update the inode's mtime.
With the change I proposed, the test shows an mtime change every ~32 secs
which corresponds to when the client writes the data to the server. Before
this change, the test only showed one mtime change, even when it was run
for > 10 mins. I did not see any increase in the calls to either
nfs_revalidate_inode() or __nfs_revalidate_inode().
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.
Regards,
Linda
next prev parent reply other threads:[~2005-04-08 20:54 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 [this message]
2005-04-09 1:23 ` Linda Dunaphant
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=1112993686.7459.4.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