[NFS] some strangeness (at least) with linux-2.4.17-NFS_ALL patch

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Hans-Peter Jansen <hpj@urpla.net> writes:

     > The problem is, ls on the client side complains about an I/O
     > error, when listing the conf/ dir.

What server is this?

     > After removing this symlink (within the server), ls is OK
     > within the client. Trying to copy servers /etc/ou.conf file to
     > /usr/share/openuniverse within the client, cp complains about
     > to many levels of symlinks?!? (/usr is shared)

That can happen, yes. The symlink is still in the dcache, and so the
VFS thinks that we want to open whatever it is that the symlink is
pointing to (not the symlink itself). For this reason, less strict
checking is performed, and so the client does not immediately see the
change.

If, however, you had first done 'ls -l' or something that tries to
read the symlink itself, more strict revalidation checks are
performed, and the stale dentry would have been detected.

I can tighten the checks on this sort of thing a bit, but if so, it
needs to be done carefully. It is important to make sure that
operations like
   'ls /usr/lib/*'
(in which you want the system to repeatedly look up the same path) are
efficient by caching the '/usr/lib' bit even if that /usr/lib is a
symlink.
Of course every time we do open("/usr/lib/libc.so"), we *do* want to
make sure that we perform strict checks when we do the lookup of the
last element of the path (on the actual file "libc.so").

Cheers,
  Trond