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

[Hans-Peter Jansen <hpj@urpla.net>]

On Friday, 11. January 2002 16:07, Trond Myklebust wrote:
> >>>>> " " == 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?

Oups, sorry: 
Linux shrek 2.4.13-ac7 #6 SMP Son Dez 2 20:02:04 CET 2001 i686 unknown
(on patches, IIRC)
>
>      > 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

Oups, correction: /usr/share/openuniverse/conf

>      > 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.

Shouldn't the client invalidate the dcache entry some time?
Now, 5 hours later, the dcache entry isn't invalidated, yet.

I think, this is a thinko. I'm not familiar with nfs internals,
but have done stuff like this before (anybody remember BioNet?).

Please try this:

shrek is the server, elfe the client
/raid is shared (reiserfs, no raid), /tmp isn't

shrek:/raid/tmp# touch /tmp/huhu
shrek:/raid/tmp# ln -s /tmp/huhu
shrek:/raid/tmp# l
total 1
drwxr-xr-x    2 root     root           55 Jan 11 20:07 ./
drwxr-xr-x    9 root     root          218 Jan 11 20:06 ../
lrwxrwxrwx    1 root     root            9 Jan 11 20:07 huhu -> /tmp/huhu

elfe:/raid/tmp# echo "huhu" > /tmp/huhu
elfe:/raid/tmp# l
insgesamt 1
drwxr-xr-x    2 root     root           55 11. Jan 20:07 ./
drwxr-xr-x    9 root     root          218 11. Jan 20:06 ../
lrwxrwxrwx    1 root     root            9 11. Jan 20:07 huhu -> /tmp/huhu
elfe:/raid/tmp# cat huhu 
huhu

shrek:/raid/tmp# rm huhu

elfe:/raid/tmp# l
insgesamt 1
drwxr-xr-x    2 root     root           35 11. Jan 20:07 ./
drwxr-xr-x    9 root     root          218 11. Jan 20:06 ../
elfe:/raid/tmp# touch huhu
elfe:/raid/tmp# l
ls: huhu: Eingabe-/Ausgabefehler
insgesamt 1
drwxr-xr-x    2 root     root           55 11. Jan 20:08 ./
drwxr-xr-x    9 root     root          218 11. Jan 20:06 ../

Pretty simple. Can you reproduce this?

> 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.

Not sure.

> 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

Thank for your patience,
Hans-Peter