From: sysmark@helios.physics.utoronto.ca (Mark Bartelt)
Subject: atime not always getting updated after read by NFS client
Reply-To: mark@cita.toronto.edu
Organization: University of Toronto Physics/Astronomy/CITA
Date: Fri, 14 Aug 1992 12:50:25 GMT

I noticed an oddity when making a tar backup of some directories yesterday.
Here's a summary ...

System "client" is a PI (IRIX 4.0.4), which NFS mounts things from a bunch
of different machines; one of its servers (named "server" in this example)
is a 4D/280 (IRIX 4.0.1).  The fstab entry on "client" includes ...

server:/d/foo             /n/server/foo        nfs     rw,hard,bg,intr 0 0
server:/d/bar             /n/server/bar        nfs     rw,hard,bg,intr 0 0

On "server", /d/foo and /d/bar are mount points for local disks.  The system
"client" has a QIC drive, so I did the following:

        cd /n/server
        tar c foo/bozo bar/bozo

All went well, but after tar completed, I looked at the atimes of the files
in the "bozo" directories.  Nearly all fell within the tar's begin/end times.
Nearly all.  But not quite all.  This is what I find mildly disturbing.  Here
are a couple examples (the tar began just before 15:00 and ran until sometime
after 15:10) ...

   # cd /n/server/foo/bozo/dust
   # ls -ltura | sed 5q 
   total 12801
   -rwxr-xr-x   1 bozo     spam      106496 Aug 12 13:47 tau
   drwxr-xr-x   2 bozo     spam         512 Aug 13 15:00 Opt
   -rw-r--r--   1 bozo     spam         836 Aug 13 15:00 .smhist
   -rw-r--r--   1 bozo     spam        6720 Aug 13 15:00 conv.den
   # 
   # cd /n/server/bar/bozo
   # 
   # ls -ltura | sed 5q
   total 10368
   -rw-r--r--   1 bozo     spam           0 Jul 31 09:01 .csherc
   -rw-r--r--   1 bozo     spam         166 Aug 13 15:02 .Xdefaults
   -rw-r--r--   1 bozo     spam        3008 Aug 13 15:02 .awmrc
   -rw-r--r--   1 bozo     spam        5267 Aug 13 15:02 .cshrc

The atimes are the same whether viewed from the client or server machine.  In
other words, the above examples were done on the client, but logging in on the
server and doing the same thing (using "/d/xxx" in place of "/n/server/xxx", of
course) produces identical results.

At first I was concerned that tar (or maybe readdir()) had a bug, and that the
files with unchanged atimes had just been missed.  But I checked the tape, and
the files in question are in fact there.

Looks like an NFS botch, right?  Anyone noticed it before?  Am I right to be
concerned?  (If NFS doesn't get the atimes right, for example, how can I be
confident that it will get other things right?  The mtimes, for example; if
I can't count on mtimes being right, I can't count on "make" always working
correctly.  And if it can't get the atimes/mtimes right, how can I trust it
to be transferring data correctly?)

By the way, in case it's relevant (though I don't know why it should be), the
tar was run by root on "client", and "server" exports /d/foo and /d/bar with
a "-root=client" option.

Anxiety-riddenly yours,

Mark Bartelt                                                    416/978-5619
Canadian Institute for                                 mark@cita.toronto.edu
Theoretical Astrophysics                               mark@cita.utoronto.ca

"Clothes not busy being worn are busy drying."    -    Dylan, on laundry day