home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.sgi
- Path: sparky!uunet!usc!rpi!utcsri!helios.physics.utoronto.ca!sysmark
- From: sysmark@helios.physics.utoronto.ca (Mark Bartelt)
- Subject: atime not always getting updated after read by NFS client
- Message-ID: <Bsz502.Jsw@helios.physics.utoronto.ca>
- Sender: news@helios.physics.utoronto.ca (News Administrator)
- Reply-To: mark@cita.toronto.edu
- Organization: University of Toronto Physics/Astronomy/CITA
- Date: Fri, 14 Aug 1992 12:50:25 GMT
- Lines: 66
-
- 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
-