Re: NFS bug (2.1.42..2.1.48)

Claus-Justus Heine (Heine@physik.rwth-aachen.de)
07 Aug 1997 04:14:01 +0200

hpa@transmeta.com (H. Peter Anvin) writes:

>
> It seems all versions of Linux from 2.1.42 on has had a problem that
> it doesn't see a file that is created on an NFS system *by the same
> system* immediately, but only some 5 seconds later. Now, I know the
> network coherency issues are tricky, but it is a pretty severe bug for
> the *same* system that creates the file not to see it immediately.
> This, among other things, breaks configure (and has eaten my .newsrc
> file far too many times :()

Mmh. Are you really sure?

I use 2.1.48 with my private patches to swap via NFS, root FS via NFS,
everything else via NFS. When I do a

touch /tmp/foo

I really see /tmp/foo AT ONCE, no problem. At least your "doesn't see
the created file at once" needs to be a bit more explained?

Indeed, I had some "pseudo" problem:

"make zImage" complained about "include/linux/compile.h" to have a
"modification time in the future". But this turned out to be a time
synchronization problem between the NFS client and server. Using some
suitable daemon solved this (i.e. netkit-timed-0.10 with some bugfix
for glibc-2.*). Maybe your's is also a time sync problem?

Ok, I don't know whether NFS should fake the modification time to
correspond to the local host's time, but tracking this down would at
least give a hint where to search for the problem, i.e. whether such a
"fake modification" time has to be introduced, or whether there are
some other bugs inside the NFS stuff.

Cheers

Claus

-- 
  Claus-Justus Heine             
  claus@momo.math.rwth-aachen.de 
  http://samuel.math.rwth-aachen.de/~LBFM/claus


  PGP Public Key:
  http://samuel.math.rwth-aachen.de/~LBFM/claus/claus-public-key.asc


  Ftape - the Linux Floppy Tape Project
  WWW         : http://samuel.math.rwth-aachen.de/~LBFM/claus/ftape
  Mailing-list: linux-tape@vger.rutgers.edu