Re: [PATCH] mtime attribute is not being updated on client

[Trond Myklebust]

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 <trond.myklebust@xxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/