Of all the gin joints in all the towns in all the world, Matthew Dillon
had to walk into mine and say:
> :> Ah ha! Yes, 32K packets will certainly screw up NFS under FreeBSD.
> :
> :Uh.... could you elaborate a little? No, strike that: could you elaborate
> :a *lot*. A whole lot.
>
> Sure. There is a constant called NFS_MAXDATA defined in ..mmm..
> nfs/nfsproto.h. Set to 32768 for TCP connections, 16384 for UDP
> connections. The code is a mess though, so usually just the higher
> limit is used. The fsinfo rpc returns this maximum to the client.
>
> The client is supposed to limit NFS packets to the specified size.
Okay. Well, I experimented a bit, and found that if I increased
NFS_MAXPACKET by 512 bytes, the machines no longer panic. (Yes, that's
NFS_MAXPACKET, not NFS_MAXDATA.) 512 is just a number I pulled out of my
ass: initially I just tried increasing it by 372 bytes (33544 -
NFS_MAXPACKET == 372) which got me a little further along, but later I
got another crash where mbuf siz was 33632. So I tried 512 and was able
to do a complete du on /usr without any problems.
As for the trashed mbuf chain I thought I saw, I was confused by a
couple of factors:
- When you do gdb -k vmunix vmcore.X, values on the stack such as
automatic variables aren't reliably preserved. In this case I
was trying to do a "print *m" to observe the contents of the last
used mbuf and this pointed me off into space somewhere. It should
have been NULL since m_next off the last mbuf in a chain is NULL.
- I was looking at m_pkthdr.rcvif and m_pkthdr.len of mreq, which were
not initialized and hence were also bogus (which makes sense since
this was an mbuf chain to be transmitted, not the request that
was received). Following the mbuf chain along showed that it
was in fact sane.
I don't know where these extra bytes are coming from. Presumeably there
is some upper bound to the size of an NFS v3 RPC; either we are computing
it wrong or SGI is. What I'd love to be able to do is snoop the requests
coming from the SGI but that's hard since they're encapsulated in a TCP
stream.
-Bill
--
=============================================================================
-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home: [EMAIL PROTECTED] | Columbia University, New York City
=============================================================================
"It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=============================================================================
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
