Re: NFS bug in 2.1.48

Claus-Justus Heine (Heine@physik.rwth-aachen.de)
19 Aug 1997 15:17:27 +0200


Systemkennung Linux <linux@mailhost.uni-koblenz.de> writes:

>
> > > #!/bin/bash
> > > cat >/tmp/xxx <<BUGGY
> > > asdf
> > > BUGGY
>
> [...]
>
> > Your little script, however, does NOT result in this error (talking
> > about 2.1.49). But there definitely is something wrong. What really
> > strikes me that both constructs don't fiddle with file descriptors
> > located on a NFS file system, only with pipes between processes. That
> > -ESTALE error _should_ be impossible.
>
> Here documents are placed in a file in $TMPDIR by the shell. They do
> not use pipes in any shell I know of.

Too true.

Ok, the original problem was that -ESTALE error. The reason for the
"stale NFS file handle" is a missing feature of the 2.1.* NFS client
code. The problem is that the NFS protocol (at least for version 2
NFS) "nfs_proc_remove()"-call REALLY removes a file on the
server. However, normal UNIX behavior is, that a remove() call removes
the directory entry, but if there still exist open file handles for
this file, the file itself isn't really removed. This only happens
after all filehandles open on this file have been closed. Now, the old
NFS client code in 2.0.* used to handle this problem like follows:

If somebody tries to remove a file that still is accessed with another
file handle, it isn't really removed (i.e. there is no proc_remove call
to the server) but it is renamed to a temporary file in the same
directory with the name ".nfs_some_unique_number". The temporary file
is removed after the last filehandle on this file has been closed.

The problem with the 2.1.* NFS client code is that a "silly rename"
feature isn't yet implemented. Hence the "stale NFS file handle"
errors with Here documents:

The shell creates a temporary file, directs it to the stdin of its
child and removes the file directly afterwards. For 2.1.* NFS this
means, that a proc_remove() call is scheduled and the file is REALLY
removed, instead of only removing its directory entry and keeping its
content until the last filehandle is closed.

So, one would need to implement that silly rename stuff for 2.1.*
There are already some places in 2.1.* NFS client code marked where
this should be done (grep for "silly" in `fs/nfs`).

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