Re: atimes not updated over NFS

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Jan 14, 2008 at 06:51:23PM +0100, Frank van Maarseveen wrote:
> On Mon, Jan 14, 2008 at 10:43:12AM -0500, Trond Myklebust wrote:
> > 
> > On Mon, 2008-01-14 at 09:34 +0100, Frank van Maarseveen wrote:
> > > On Thu, Jan 10, 2008 at 12:51:53AM +0100, Andre Majorel wrote:
> > > > On 2008-01-09 18:23 -0500, Trond Myklebust wrote:
> > > > > On Wed, 2008-01-09 at 23:37 +0100, Andre Majorel wrote:
> > > > >
> > > > > > I'll take your word for it. However, let me assure you that atimes
> > > > > > somehow used to work over NFS, even for files small enough to fit
> > > > > > in the cache. Had they been broken, I would have known. I use Mutt.
> > > > > 
> > > > > How would the server know to update the atime? If the file is in cache
> > > > > we don't READ.
> > > > 
> > > > You tell me. All I can tell you is that Mutt used to work so
> > > > atimes were updated one way or another.
> > > 
> > > I think 2.6.22 introduced this regression. On 2.6.22.10, reading a file
> > > on NFS does not affect atime according to stat(), not on the client and
> > > not on the server. This breaks several programs.
> > > 
> > > Commands to reproduce this problem on the client:
> > > 
> > > 	dd </dev/zero >testfile count=1
> > > 	ls -l --time=atime --full-time testfile
> > > 	sleep 2
> > > 	wc testfile
> > > 	ls -l --time=atime --full-time testfile
> > > 		(same atime, not good)
> > 
> > Can you confirm that it does not change on the server? If so, then we
> > need to look at the server for a fix. The client should only be
> > mirroring the server's idea of the correct atime.
> 
> It doesn't change on the server (2.6.23.12)

That still leaves open the question as to whether this is due to changes
in the client that are causing it not to issue a read to the server when
it would have before, or whether the server is just refusing to update
the atime on read for some reason....

--b.