From owner-freebsd-bugs Tue Apr 22 10:29:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26891 for bugs-outgoing; Tue, 22 Apr 1997 10:29:39 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA26880 for ; Tue, 22 Apr 1997 10:29:35 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id SAA11905; Tue, 22 Apr 1997 18:28:49 +0100 (BST) Date: Tue, 22 Apr 1997 18:28:49 +0100 (BST) From: Doug Rabson To: Thomas David Rivers cc: freebsd-bugs@freebsd.org Subject: Re: kern/3304: NFS V2 readdir hangs In-Reply-To: <199704221542.LAA04318@lakes.water.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Apr 1997, Thomas David Rivers wrote: > > > > On Mon, 21 Apr 1997, Thomas David Rivers wrote: > > > > > > I think the most promising candidate is the 'full socket buffers' message. > > > > Could you see if that goes up consistently when you prompt the system to > > > > hang. The match between that and the reassembly number seems to show that > > > > these are large packets. > > > > > > We'll do! > > > > I have been looking at the code again today and it seems to me that the > > client is not reserving enough space in its sockets when it initialises > > the mount. Your nasty directory appears to generate a reply packet which > > is too large for the client to recieve. > > > > I added some code to use a slightly less restrictive buffer size in the > > NFS client. I also tidied up the code which sets the size for readdir > > requests to make it possible to set it to less than 4k and to be more > > compatible with 2.1.x. Could you try this patch, both with and without a > > -r1024 argument to mount_nfs. > > > I tried it out with a -r1024 (and -w1024, which shouldn't matter) > and without any options except -t60... > > It worked wonderfully!!! I'd say commit that patch!!! (thanks again) > > Now, I see you set the rcvreserve to "(nm_rsize + NFS_MAXPKTHDR) * 2" > which, for me was enough - but can we determine just what is 'really' > enough, or is this just a better guess? [Is it guaranteed to be > enough because you bump the readdirsize down to the rsize is rsize > is the lesser of the two?] In the existing code, the main problem I can see is that nm_readdirsize is allowed to be larger than nm_rsize and indeed is forced to be a minimum of 4k for some spurious reason. This would mean that if you set nm_rsize to 1024, you would be guaranteed a hang for the first readdir larger than about 1200 bytes. Did your hang happen with or without -r1024, or both? I still don't quite understand the rules used by the socketbuf for these sizes. It may be that just forcing nm_readdirsize <= nm_rsize is enough. I doubled the size to make it the same as the SEQPACKET and STREAM case; I don't think it will do any harm to leave it doubled. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891