Date: Thu, 29 Jul 1999 00:40:03 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: cross@cs.rpi.edu, current@freebsd.org Subject: Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm Message-ID: <199907290440.AAA15847@skynet.ctr.columbia.edu> In-Reply-To: <199907282358.QAA64519@apollo.backplane.com> from "Matthew Dillon" at Jul 28, 99 04:58:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907290440.AAA15847>