I am wondering if this is a known bug and what Linux versions are
affected by it. Or if it might be a Red Hat only bug.
I am using utimes() to set the atime/mtime of a file to 0 (i.e. the
start of the Epoch).
When I stat this file on the server and on most of my NFS clients the
atime/mtime are 0, but on some of the clients the atime is reported as
0 and the mtime is some other random time (sometimes the current time,
sometimes a time within the last few hours, but sometimes a time that
is years ago). Here is a sample of incorrect times (run at ~11:41):
Mon Jun 14 11:40:52 2004 ***
Wed Jun 9 23:50:00 2004
Tue Jun 17 09:46:31 2003
Mon Jun 25 03:14:47 2001
Mon Jun 14 11:41:11 2004 ***
Mon Jun 14 10:51:48 2004
Mon Jun 14 10:33:23 2004
Mon Jun 14 10:10:00 2004
Mon Jun 14 10:52:11 2004
Mon Jun 14 11:23:57 2004
Mon Jun 14 11:41:15 2004 ***
Mon Jun 14 11:12:52 2004
Thu Apr 11 09:25:14 2002
Sat Jun 12 19:38:43 2004
Mon Jun 14 09:49:52 2004
Mon Jun 14 11:31:21 2004
(The "***" indicates when the mtime equaled the current time.)
Some of these times persist between repeated tests, but they all seem
to change eventually.
Everything is fine when the atime/mtime is 1 (i.e. one second after
the start of the Epoch).
The clients that report correctly are:
2.4.9-13smp
2.4.9-31
2.4.9-34
The clients that report incorrectly are:
2.4.20-13.7
2.4.20-13.7smp
2.4.20-28.7
2.4.20-29.7.progeny.3
The server is running 2.4.20-29.7.progeny.4.
These are all "Red Hat Linux release 7.2 (Enigma)" releases.
Any insight would be appreciated.
--
Daniel K. Forrest Laboratory for Molecular and
[email protected] Computational Genomics
University of Wisconsin, Madison
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
P=E5 m=E5 , 14/06/2004 klokka 12:57, skreiv Daniel Forrest:
> I am wondering if this is a known bug and what Linux versions are
> affected by it. Or if it might be a Red Hat only bug.
>=20
> I am using utimes() to set the atime/mtime of a file to 0 (i.e. the
> start of the Epoch).
So are you doing this on the server or on the client? If the former,
then you shouldn't expect any updates to atime/mtime to be registered
until the attribute cache has expired on the client (see "man 5 nfs" for
a description of the mount options that control the length of the cache
timeout).
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
Trond,
>> So are you doing this on the server or on the client? If the
>> former, then you shouldn't expect any updates to atime/mtime to be
>> registered until the attribute cache has expired on the client (see
>> "man 5 nfs" for a description of the mount options that control the
>> length of the cache timeout).
It doesn't matter where I set the atime/mtime from.
Certain clients report an incorrect mtime regardless of how long it
has been since the atime/mtime was set.
For instance:
On the server:
# touch -d "00:00:00 1/1/70GMT" timestamp0
Which is creating a file "timestamp0" that did not exist before, so
there are no attributes that can be cached.
On a 2.4.20 client:
$ TZ=GMT stat timestamp0
File: "timestamp0"
Size: 0 Blocks: 0 IO Block: 4096 Regular File
Device: ch/12d Inode: 14483498 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 101/ users)
Access: Thu Jan 1 00:00:00 1970
Modify: Mon Jun 14 19:15:01 2004
Change: Mon Jun 14 19:14:57 2004
Note that in this instance, the returned mtime is equal to the current
time, this is not always the case. (Also, this incorrect value has
persisted for 25 minutes since I first checked.) Other 2.4.20 clients
report different (but always incorrect) mtimes, while 2.4.9 clients
report the mtime correctly.
Back on the server:
# touch -d "00:00:01 1/1/70GMT" timestamp1
Which is creating a file "timestamp1" that did not exist before.
Back on the 2.4.20 client:
$ TZ=GMT stat timestamp1
File: "timestamp1"
Size: 0 Blocks: 0 IO Block: 4096 Regular File
Device: ch/12d Inode: 14483770 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 101/ users)
Access: Thu Jan 1 00:00:01 1970
Modify: Thu Jan 1 00:00:01 1970
Change: Mon Jun 14 19:16:13 2004
Note that in this case (1 second into the Epoch) the returned values
are correct on this and all other clients.
In general, when the mtime is 0, the 2.4.20 clients never report the
correct mtime. Different clients report different mtimes when queried
at the same time. A specific client will persist in reporting the
same incorrect mtime for a while, but the value does change over time
and never is correct.
--
Daniel K. Forrest Laboratory for Molecular and
[email protected] Computational Genomics
University of Wisconsin, Madison
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 m=E5 , 14/06/2004 klokka 15:41, skreiv Daniel Forrest:
> It doesn't matter where I set the atime/mtime from.
>=20
> Certain clients report an incorrect mtime regardless of how long it
> has been since the atime/mtime was set.
I'm unable to reproduce this on a 2.4.21 RHEL client. Ditto on both
stock 2.4.26-pre2 and 2.6.5 kernels from ftp.kernel.org.
Are you able to compile up a more recent 2.4.x kernel, to see if you can
reproduce the problem?
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Monday June 14, [email protected] wrote:
> I am wondering if this is a known bug and what Linux versions are
> affected by it. Or if it might be a Red Hat only bug.
>
> I am using utimes() to set the atime/mtime of a file to 0 (i.e. the
> start of the Epoch).
>
> When I stat this file on the server and on most of my NFS clients the
> atime/mtime are 0, but on some of the clients the atime is reported as
> 0 and the mtime is some other random time (sometimes the current time,
> sometimes a time within the last few hours, but sometimes a time that
> is years ago). Here is a sample of incorrect times (run at ~11:41):
>
> Mon Jun 14 11:40:52 2004 ***
> Wed Jun 9 23:50:00 2004
> Tue Jun 17 09:46:31 2003
> Mon Jun 25 03:14:47 2001
> Mon Jun 14 11:41:11 2004 ***
> Mon Jun 14 10:51:48 2004
> Mon Jun 14 10:33:23 2004
> Mon Jun 14 10:10:00 2004
> Mon Jun 14 10:52:11 2004
> Mon Jun 14 11:23:57 2004
> Mon Jun 14 11:41:15 2004 ***
> Mon Jun 14 11:12:52 2004
> Thu Apr 11 09:25:14 2002
> Sat Jun 12 19:38:43 2004
> Mon Jun 14 09:49:52 2004
> Mon Jun 14 11:31:21 2004
>
> (The "***" indicates when the mtime equaled the current time.)
I tripped over this about 18 months ago.
The problem happens at in __nfs_refresh_inode in fs/nfs/inode.c
There is a code fragment:
if (NFS_CACHE_MTIME(inode) != new_mtime) {
NFS_MTIME_UPDATE(inode) = jiffies;
NFS_CACHE_MTIME(inode) = new_mtime;
inode->i_mtime = nfs_time_to_secs(new_mtime);
}
NFS has just received some attributes for a file from the server. It
has a fresh "struct inode" and wants to fill in the fields.
In this "struct inode", NFS_CACHE_MTIME is initialised to zero by
alloc_inode (in fs/inode.c).
As new_mtime is 0, it appears to be the same as
NFS_CACHE_MTIME(inode), and so inode->i_mtime is not updated.
inode->i_mtime is *not* initialised by alloc_inode, and so has
whatever the value was for the last inode to use this piece of memory.
The simplest fix is probably to add:
inode->i_mtime = 0;
near the top of nfs_read_inode in fs/nfs/inode.c
NeilBrown
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 m=E5 , 14/06/2004 klokka 19:10, skreiv Neil Brown:
> The simplest fix is probably to add:
>=20
> inode->i_mtime =3D 0;
>=20
> near the top of nfs_read_inode in fs/nfs/inode.c
Ah... That indeed looks plausible.
It's probably better to fix nfs_fill_inode() though. We want to make
sure it initializes all fields of the inode regardless of what checks
made by nfs_refresh_inode().
I'll code up a patch after dinner.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs