Ultrix 4.1 NFS bug

Robert Thurlow thurlow at convex.com
Fri Feb 22 08:48:39 AEST 1991


In <1991Feb21.172023.19905 at cimage.com> brian at 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 at convex.com
An employee and not a spokesman for Convex Computer Corp., Dallas, TX



More information about the Comp.unix.ultrix mailing list