On Mon, Jun 28, 2021 at 4:28 PM Nick Couchman <nick.e.couchman(a)gmail.com
wrote:
On Mon, Jun 28, 2021 at 4:21 PM Frank Filz
<ffilzlnx(a)mindspring.com
wrote:
> Hmm, we do need to make that SEGFAULT not happen… Directories will be
> missing in life…
Yes, I'd agree this is not ideal behavior - I would think if Handle
Mapping is enabled and the directory does not exist, the process of
configuring that export ought to be completely stopped.
> Get a tcpdump and look at where
the handle that is causing the stale
> handle error is coming from. Do we handle map the handles shared in READDIR?
I put the tshark output in a pastebin and replied with that to the
previous e-mail. If I can provide any more detail let me know. I think it's
the root handle that is causing it, since it happens during mount?? But
this level of NFS detail is very new to me :-).
Actually I'm not sure this is in readdir, but actually during FSINFO
processing, as the NFS3ERR_STALE response comes directly after the client
does a FSINFO request:
Frame 152: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits) on
interface 0
Ethernet II, Src: Cisco_9d:5a:42 (8c:60:4f:9d:5a:42), Dst:
b2:5a:dd:d6:98:58 (b2:5a:dd:d6:98:58)
Internet Protocol Version 4, Src: 10.1.2.5, Dst: 10.1.2.4
Transmission Control Protocol, Src Port: 889, Dst Port: 2049, Seq: 169,
Ack: 65, Len: 124
Remote Procedure Call, Type:Call XID:0x76f80e97
Fragment header: Last fragment, 120 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0000 0111 1000 = Fragment Length: 120
XID: 0x76f80e97 (1995968151)
Message Type: Call (0)
RPC Version: 2
Program: NFS (100003)
Program Version: 3
Procedure: FSINFO (19)
Credentials
Flavor: AUTH_UNIX (1)
Length: 52
Stamp: 0x00000000
Machine Name:
nfs-client.example.com
length: 25
contents:
nfs-client.example.com
fill bytes: opaque data
UID: 0
GID: 0
Auxiliary GIDs (1) [0]
GID: 0
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Network File System, FSINFO Call DH: 0xb2a31f30
[Program Version: 3]
[V3 Procedure: FSINFO (19)]
object
length: 24
[hash (CRC-32): 0xb2a31f30]
FileHandle: 4300038610102300006eb32fce0000000000000000000000
Frame 153: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on
interface 0
Ethernet II, Src: b2:5a:dd:d6:98:58 (b2:5a:dd:d6:98:58), Dst:
Cisco_9f:f0:6a (00:00:0c:9f:f0:6a)
Internet Protocol Version 4, Src: 10.1.2.4, Dst: 10.1.2.5
Transmission Control Protocol, Src Port: 2049, Dst Port: 889, Seq: 65, Ack:
293, Len: 36
Remote Procedure Call, Type:Reply XID:0x76f80e97
Fragment header: Last fragment, 32 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0000 0010 0000 = Fragment Length: 32
XID: 0x76f80e97 (1995968151)
Message Type: Reply (1)
[Program: NFS (100003)]
[Program Version: 3]
[Procedure: FSINFO (19)]
Reply State: accepted (0)
[This is a reply to a request in frame 152]
[Time from request: 0.000301532 seconds]
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Accept State: RPC executed successfully (0)
Network File System, FSINFO Reply Error: NFS3ERR_STALE
[Program Version: 3]
[V3 Procedure: FSINFO (19)]
Status: NFS3ERR_STALE (70)
obj_attributes
attributes_follow: no value (0)
-Nick