Re: 2.2.10-ac<x> / 2.2.11-pre<x> NFS client problem & bugfix

Frank van Maarseveen (fvm@tasking.nl)
Thu, 5 Aug 1999 15:16:13 +0200

On Thu, Aug 05, 1999 at 02:53:46PM +0200, Trond Myklebust wrote:
> This will in most cases put an unreasonable burden on the network with
> huge numbers of NFS_LOOKUP requests. Linus rejected a similar patch
> around the pre-patch-2.2.8 series for this very reason. The current
> code was the best compromise that could be reached.
But it doesn't work in certain cases and it is not even an optional
"feature". For example, certain programs are not available for Linux
but they are for other UNIXes. So in our company we do a rsh to the
server (OSF/1 4.0) to execute the command there, all automated. This
breaks due to negative dentry caching. Now we always have to patch the
Linux kernel because of this unconditional "feature".

2.2.6-ac3 and other prior versions did not have this behavior and to
my knowledge no other UNIX client currently does (AFAIK only OSF/1 3.2
NFS did something which is even more evil, rendering it *completely*
useless).

> It will work quite reasonably for UNIX filesystems (except for entries
> just below the mountpoint for which we currently have a small bug in
> the updating of attributes), but may indeed be a problem for
> VFAT-style filesystems that don't update directory mtimes.
>
> Where are you BTW seeing persistent negative dentries? They should
> never occur.
To repeat my mail:

==>Run this on the client in a separate window:
==>
==> while usleep 100000; do ls notfound; done
==>
==>Go to the server and create the "notfound" file. The client script will
==>never see this file due to caching. When the usleep is increased towards
==>1 second then the file will be found in most cases (but not all --
==>different issues).

To rephrase: The while loop will never find the file if it's too tight (<1
sec).

Regards,

-- 
Frank


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/