brian@cimage.com (Brian Kelley) (02/22/91)
We seem to have found a bug in the Ultrix (RISC) 4.1 NFS. I'm not an NFS expert, so if this is a feature, please clue me in. Ultrix NFS seems to cache inodes (at least that's what I would call it). Given: Filesystem /c2 is remotely NFS mounted from fileserver dgsi. euler is a Sun Sparc which NFS mounts /c2. fifo is a DecSystem 5400 which also NFS mounts /c2. On fifo, create a file on /c2/tmp: fifo>touch /c2/tmp/foo.dec On euler, do the same: euler>touch /c2/tmp/foo.sun From both hosts, an ls -l /c2/tmp/foo.* looks the same: -rw-r--r-- 1 brian 0 Feb 21 12:02 foo.dec -rw-r--r-- 1 brian 0 Feb 21 12:02 foo.sun Now, on the Sun, I do the following: euler>/usr/5bin/touch 01010101 /c2/tmp/foo.sun euler>ls -l /c2/tmp/foo.* -rw-r--r-- 1 brian 0 Feb 21 12:02 foo.dec -rw-r--r-- 1 brian 0 Jan 1 01:01 foo.sun Looks good. But when I do an ls -l /c2/tmp/foo.* from the DEC: fifo>ls -l /c2/tmp/foo.* -rw-r--r-- 1 brian 0 Feb 21 12:02 /c2/tmp/foo.dec -rw-r--r-- 1 brian 0 Feb 21 12:02 /c2/tmp/foo.sun The DEC machine is wrong. It is caching the inode(?). And then: fifo>touch 01010101 foo.dec fifo>ls -l foo.* -rw-r--r-- 1 brian 0 Feb 21 12:02 foo.dec -rw-r--r-- 1 brian 0 Feb 21 12:02 foo.sun Gee, that didn't seem to work. And bouncing back over to the Sun: euler>ls -l foo.* -rw-r--r-- 1 brian 0 Jan 1 01:01 foo.dec -rw-r--r-- 1 brian 0 Jan 1 01:01 foo.sun So the touch command on the DEC did change the inode, but even that wasn't enough to invalidate the cache. Yuck!! Looks like a bug to me. For software development with NFS and make, it causes some pain. Or is something else happening? -Brian --- brian@cimage.com
thurlow@convex.com (Robert Thurlow) (02/22/91)
In <1991Feb21.172023.19905@cimage.com> brian@cimage.com (Brian Kelley) writes: >Ultrix NFS seems to cache inodes (at least that's what I would call it). NFS clients may indeed cache the meta-data associated with the file (a.k.a. the attributes) for a period of time. (It doesn't have, need or want all of the inode data, but does have stuff like the mod time, size, permission bits, etc.) This time period is normally adjustable on a per-mounted-fs basis, and can be tuned to be different for file and directory objects if desired, and may be turned off (which might even work now in 4.1 - it didn't in SunOS 4.0). Now, that won't help you, because you're outsmarting the algorithm. Read on. After this 'cache attributes' time limit has passed, many operations over NFS will fetch a new set of attributes. If the new attributes carry a newer modification time, the attributes will be installed and the cached bages in the buffer cache will be burned. Your test case sets the server attributes _older_ than the client version, so the client will not flush attributes at all. If you do a normal 'touch' on the server, you should see the client pick up the change within a few seconds, depending on your mount options. Since most makefiles don't hammer a phony date into the mod time, this works reasonably well, but it is something to remember. If it's a real problem, you should be able to bypass the attribute cache with a mount option. Rob T -- Rob Thurlow, thurlow@convex.com An employee and not a spokesman for Convex Computer Corp., Dallas, TX