to den 07.04.2005 Klokka 20:52 (-0400) skreiv Linda Dunaphant:
> Hi Trond,
>
> The acregmin (default=3) and acregmax (default=60) NFS attributes that
> control the min and max attribute cache lifetimes don't appear to be
> working after the first few timeouts. Using a test program that loops
> on the following sequence:
> - write to a file on an NFS3 mounted filesystem from the client
> - sleep for one second
> - stat the file to get the mtime
> you see the mtime change once after ~56 seconds, but no further mtime
> changes are detected by the test.
>
> nfs_refresh_inode() currently bypasses the inode vs fattr mtime comparison
> if data_unstable is true. At the end of nfs_refresh_inode(), it resets the
> attribute timer. Since nfs_refresh_inode() is being called after every
> write to the server (which occurs more often than the attribute timer is
> set to expire), the attribute timer never expires again for this file past
> the ~56 sec point.
>
> In nfs_refresh_inode() I believe the mtime comparison should be moved outside
> the check for data_unstable. The server might already have a newer value for
> mtime than the value on the client. With this change, the test sees the mtime
> change after each write completes on the server.
>
> Regards,
> Linda
Hi Linda,
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
--
Trond Myklebust <[email protected]>
-
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]
