Linux 2.2.13 disagrees with unfsd 2.2beta8 and 2.2beta48

Russell King (rmk@arm.linux.org.uk)
Thu, 18 Nov 1999 21:14:38 +0000 (GMT)


Hi,

I'm experiencing problems with Linux 2.2.13 talking to unfsd 2.2beta8 and
2.2beta48. The following problem was noticed after upgrading to Linux 2.2.12.

I am exporting my /usr/src partition to my other boxes to allow multiple
parrallel kernel building. The kernel build on the clients happily trots
along until it compiles up version.c, where I see:

arm-linux-gcc -D__KERNEL__ -I/net/raistlin/src/v2.2/linux-ebsa285/include -m6 -Wall -Wstrict-prototype
s -O2 -pipe -DUTS_MACHINE='"arm"' -c -o init/version.o init/version.c
cpp: /net/raistlin/src/v2.2/linux-ebsa285/include/linux/version.h: I/O error
cpp: /net/raistlin/src/v2.2/linux-ebsa285/include/linux/compile.h: I/O error

Note: the problem is exhasibated with 2.2beta48 - 2.2beta8 only complained
about compile.h.

The makefiles create compile.h by writing to (in this case)
/net/raistlin/src/v2.2/linux-ebsa285/.ver, and then renaming that file to
/net/raistlin/src/v2.2/linux-ebsa285/include/linux/compile.h

The problem appears to be that Linux 2.2.13 retains the NFS filehandle for
.ver and uses it when attempting to read include/linux/compile.h. Here
follows an edited tcpdump (with the nfs filehandles) of the problem:

12.b0.2.7a.4.7a.b4.37.3f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.081783 flint.967ede08 > raistlin.nfs: 172 create fh Unknown/1 ".ver"
2.b0.2.7a.5.7a.b4.37.3f.da.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.081783 raistlin.nfs > flint.967ede08: reply ok 128 create fh Unknown/1
2.b0.2.7a.5.7a.b4.37.3f.da.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.081783 flint.977ede08 > raistlin.nfs: 172 write fh Unknown/1 24 (24) bytes @ 0 (0)
21:04:38.091783 raistlin.nfs > flint.977ede08: reply ok 96 write

<<many more writes>>

12.b0.2.7a.4.7a.b4.37.3f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.711777 flint.b97ede08 > raistlin.nfs: 140 lookup fh Unknown/1 ".ver"
2.b0.2.7a.5.7a.b4.37.3f.da.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.711777 raistlin.nfs > flint.b97ede08: reply ok 128 lookup fh Unknown/1
2.b0.2.7a.5.7a.b4.37.3f.da.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.711777 flint.ba7ede08 > raistlin.nfs: 196 write fh Unknown/1 45 (45) bytes @ 191 (191)
21:04:38.721777 raistlin.nfs > flint.ba7ede08: reply ok 96 write

12.b0.2.7a.4.7a.b4.37.3f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.751777 flint.bf7ede08 > raistlin.nfs: 140 lookup fh Unknown/1 ".ver"
2.b0.2.7a.5.7a.b4.37.3f.da.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.751777 raistlin.nfs > flint.bf7ede08: reply ok 128 lookup fh Unknown/1
12.b0.2.7a.4.7a.b4.37.3f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
aa.b9.1.7a.6.7a.b4.37.3f.da.5a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.751777 flint.c07ede08 > raistlin.nfs: 188 rename fh Unknown/1 ".ver" -> fh Unknown/1 "compile.h"

2.b0.2.7a.5.7a.b4.37.3f.da.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:04:38.861776 flint.c87ede08 > raistlin.nfs: 144 read fh Unknown/1 4096 bytes @ 0
21:04:38.871776 raistlin.nfs > flint.c87ede08: reply ok 28 read ERROR: Communication error on send [|nfs]

The correct filehandle is:
aa.b9.1.7a.6.7a.b4.37.3f.da.5a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:09:52.448753 flint.e07ede08 > raistlin.nfs: 148 lookup fh Unknown/1 "compile.h"
2.b0.2.7a.7.7a.b4.37.3f.da.5a.68.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
21:09:52.458753 raistlin.nfs > flint.e07ede08: reply ok 128 lookup fh Unknown/1

As you can see, Linux 2.2.13 appears to cache the nfs filehandle across
a rename.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King rmk@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |

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