After upgrading an NFS server from kernel 2.6.12 to 2.6.23, the
atime of files is not updated any more when clients read them :
client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
-rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
client$ md5sum /nfsmnt/zz
d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz
client$ date +%Y-%m-%d_%H:%M:%S
2007-12-21_15:00:28
client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
-rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
Reading the file locally, i.e. on the NFS server, does update the
atime :
server$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
-rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
serveur$ md5sum /nfsmnt/zz
d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz
serveur$ date +%Y-%m-%d_%H:%M:%S
2007-12-21_15:04:00
serveur$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
-rw-r--r-- 1 xxx xxx 0 2007-12-21_15:03:57 /nfsmnt/zz
/nfsmnt is mounted with options :
- server : rw,noexec,nosuid,nodev,nodiratime
- client : rw,user=3Droot,nosuid,nodev,nodiratime,intr,rsize=3D8192,wsi=
ze=3D8192
Any ideas ?
--=20
Andr=E9 Majorel <URL:http://www.teaser.fr/~amajorel/>
Do not use this account for regular correspondence.
See the URL above for contact information.
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.
On Mon, 2008-01-21 at 14:06 -0500, J. Bruce Fields wrote:
> > > > 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....
A script of the form
ssh server 'dd </dev/zero >testfile count=1; ls -l --time=atime --full-time testfile'
cat testfile >/dev/null
ssh server 'ls -l --time=atime --full-time testfile'
ls -l --time=atime --full-time testfile
should normally force the client to read the file, and should tell if
the atime is being updates correctly on both server and client.
Cheers
Trond
On Wed, 2008-01-09 at 11:13 +0100, Andre Majorel wrote:
> After upgrading an NFS server from kernel 2.6.12 to 2.6.23, the
> atime of files is not updated any more when clients read them :
>
> client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
> -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
> client$ md5sum /nfsmnt/zz
> d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz
> client$ date +%Y-%m-%d_%H:%M:%S
> 2007-12-21_15:00:28
> client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
> -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
>
> Reading the file locally, i.e. on the NFS server, does update the
> atime :
>
> server$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
> -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
> serveur$ md5sum /nfsmnt/zz
> d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz
> serveur$ date +%Y-%m-%d_%H:%M:%S
> 2007-12-21_15:04:00
> serveur$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
> -rw-r--r-- 1 xxx xxx 0 2007-12-21_15:03:57 /nfsmnt/zz
>
> /nfsmnt is mounted with options :
> - server : rw,noexec,nosuid,nodev,nodiratime
> - client : rw,user=root,nosuid,nodev,nodiratime,intr,rsize=8192,wsize=8192
>
> Any ideas ?
The file is probably entirely in cache on the client. When this happens,
no READ rpc calls need to be made to the server and so the atime will
not change either.
This has always been the case, BTW...
Trond
On 2008-01-09 10:27 -0500, Trond Myklebust wrote:
> On Wed, 2008-01-09 at 11:13 +0100, Andre Majorel wrote:
>
> > After upgrading an NFS server from kernel 2.6.12 to 2.6.23, the
> > atime of files is not updated any more when clients read them :
> >=20
> > client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
> > -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
> > client$ md5sum /nfsmnt/zz
> > d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz
> > client$ date +%Y-%m-%d_%H:%M:%S
> > 2007-12-21_15:00:28
> > client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
> > -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
> >=20
> > Reading the file locally, i.e. on the NFS server, does update the
> > atime :
> >=20
> > server$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
> > -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz
> > serveur$ md5sum /nfsmnt/zz
> > d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz
> > serveur$ date +%Y-%m-%d_%H:%M:%S
> > 2007-12-21_15:04:00
> > serveur$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz
> > -rw-r--r-- 1 xxx xxx 0 2007-12-21_15:03:57 /nfsmnt/zz
> >=20
> > /nfsmnt is mounted with options :
> > - server : rw,noexec,nosuid,nodev,nodiratime
> > - client : rw,user=3Droot,nosuid,nodev,nodiratime,intr,rsize=3D8192=
,wsize=3D8192
> >=20
> > Any ideas ?
>=20
> The file is probably entirely in cache on the client. When this happe=
ns,
> no READ rpc calls need to be made to the server and so the atime will
> not change either.
The client has 512 MB of RAM. A 513-MB file cannot possibly be
cached so let's try with that.
atc5:/aym/etc$ time dd if=3D/dev/zero bs=3D1M count=3D513 >/nfsmnt/zz
513+0 records in
513+0 records out
real 0m50.412s
user 0m0.004s
sys 0m8.905s
atc5:/aym/etc$ ls -l --time-style +%Y-%m-%d_%H:%M:%S -u /nfsmnt/zz
-rw-r--r-- 1 aym aym 537919488 2007-12-21_13:46:54 /nfsmnt/zz
atc5:/aym/etc$ time wc /nfsmnt/zz
0 0 537919488 /nfsmnt/zz
real 1m30.743s
user 0m47.091s
sys 0m22.369s
atc5:/aym/etc$ date +%Y-%m-%d_%H:%M:%S
2008-01-09_23:21:06
atc5:/aym/etc$ ls -l --time-style +%Y-%m-%d_%H:%M:%S -u /nfsmnt/zz
-rw-r--r-- 1 aym aym 537919488 2007-12-21_13:46:54 /nfsmnt/zz
As the times show, the file is not in cache. And yet the atime is
still not updated.
> This has always been the case, BTW...
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.
Thanks.
--=20
Andr=E9 Majorel <URL:http://www.teaser.fr/~amajorel/>
Do not use this account for regular correspondence.
See the URL above for contact information.
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.
Trond
On Wed, 2008-01-09 at 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.
Put differently. Have you checked on the _server_ that the atime is
actually changing when you do these tests on the client?
Trond
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.
>=20
> How would the server know to update the atime? If the file is in cach=
e
> 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.
As of 2.6.23, access times are never updated, even for files that
are too big to fit in the cache. I'm willing to run tests if that
helps.
--=20
Andr=E9 Majorel <URL:http://www.teaser.fr/~amajorel/>
Do not use this account for regular correspondence.
See the URL above for contact information.
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)
--
Frank
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.
Cheers
Trond
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)
--
Frank