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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]