I am using one machine (dewey) as the NFS server, and the other
machine (louie) is the NFS client. The NFS client is compiling
using source files from the NFS server, and writing the object
files back to the NFS server.
I have some kind of synchronization problem; sometimes when a
directory is made on the NFS server, the NFS client can't see it for
a few seconds. The assembler on the NFS client fails because it
thinks the output directory does not exist.
I've been doing some network traces (I'm one of the authors of
Ethereal, BTW), and these strange "mkdir-latency" problems co-occur
with another symptom: bad NFS packets.
The following NFS packet was sent from the NFS client to the NFS
server. It's an NFS v2 LOOKUP packet. The RPC string, i.e., the
NFS filename, is misplaced. It's off by 4 bytes. (hence the subject
line of this e-mail) In my trace, the client sent over 2,000 *good*
LOOKUP packets, but at this point it sent a few *bad* ones, including
this one.
Notice at the end of the packet it looks like the filename "config.h"
was memcpy()'ed in one location, then re-memcpy()'ed
in another overlapping location.
BTW, dewey, the NFS server, correctly responds with ERR_NOENT
in it's LOOKUP reply packet. The client then sends another badly-formed
LOOKUP request, which is again replied to with "ERR_NOENT". Then
the client goes on to ask for another file, sending another badly-formed
packet.
I thought at first that there was a bug in Ethereal, but the
format of the NFS packet is indeed bad.
Frame (170 on wire, 170 captured)
Arrival Time: Dec 3, 1999 11:59:39.6631
Time delta from previous packet: 0.027926 seconds
Frame Number: 51268
Packet Length: 170 bytes
Capture Length: 170 bytes
Ethernet II
Destination: 00:c0:4f:6b:9f:e0 (00:c0:4f:6b:9f:e0)
Source: 00:c0:4f:6b:9f:78 (00:c0:4f:6b:9f:78)
Type: IP (0x0800)
Internet Protocol
Version: 4
Header length: 20 bytes
Type of service: 0x00 (None)
000. .... = Precedence: routine (0)
...0 .... = Delay: Normal
.... 0... = Throughput: Normal
.... .0.. = Reliability: Normal
.... ..0. = Cost: Normal
Total Length: 156
Identification: 0xc3d8
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x5919
Source: louie.dev.tivoli.com (146.84.28.92)
Destination: dewey.dev.tivoli.com (146.84.28.91)
User Datagram Protocol
Source port: 793 (793)
Destination port: 2049 (2049)
Length: 136
Checksum: 0xabc3
Remote Procedure Call
XID: 0x8265de80 (2187714176)
Message Type: Call (0)
RPC Version: 2
Program: NFS (100003)
Program Version: 2
Procedure: LOOKUP (4)
Credentials
Flavor: AUTH_UNIX (1)
Length: 44
Stamp: 0x000007ae
Machine Name: louie.dev.tivoli.com
length: 20
contents: louie.dev.tivoli.com
UID: 4462
GID: 40
Auxiliary GIDs
GID: 40
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Network File System
Program Version: 2
Procedure: LOOKUP (4)
where
dir
file handle (opaque data)
Name: ig.h
length: 1668247142
contents: ig.h
0 00c0 4f6b 9fe0 00c0 4f6b 9f78 0800 4500 ..Ok....Ok.x..E.
10 009c c3d8 0000 4011 5919 9254 1c5c 9254 ......@.Y..T.\.T
20 1c5b 0319 0801 0088 abc3 8265 de80 0000 .[.........e....
30 0000 0000 0002 0001 86a3 0000 0002 0000 ................
40 0004 0000 0001 0000 002c 0000 07ae 0000 .........,......
50 0014 6c6f 7569 652e 6465 762e 7469 766f ..louie.dev.tivo
60 6c69 2e63 6f6d 0000 116e 0000 0028 0000 li.com...n...(..
70 0001 0000 0028 0000 0000 0000 0000 caba .....(..........
80 ebfe 94b9 0000 5972 0000 0108 0000 0108 ......Yr........
90 0000 718f 0000 c773 890b 0000 0000 636f ..q....s......co
a0 6e66 6967 2e68 0067 2e68 nfig.h.g.h
(The NFS header starts at byte 0x7e, with "caba...")
--gilbert
-
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/