From owner-svn-src-all@FreeBSD.ORG Wed Jan 25 04:28:10 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91F08106566B; Wed, 25 Jan 2012 04:28:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 26E4F8FC17; Wed, 25 Jan 2012 04:28:09 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q0P4S7vp019291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 15:28:08 +1100 Date: Wed, 25 Jan 2012 15:28:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <2145461054.81036.1327460551572.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: <20120125152150.M1522@besplex.bde.org> References: <2145461054.81036.1327460551572.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, Rick Macklem , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans Subject: Re: svn commit: r230516 - in head/sys: fs/nfsclient nfsclient X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 04:28:10 -0000 On Tue, 24 Jan 2012, Rick Macklem wrote: > Bruce Evans wrote: >> On Wed, 25 Jan 2012, Rick Macklem wrote: >> >>> Log: >>> If a mount -u is done to either NFS client that switches it >>> from TCP to UDP and the rsize/wsize/readdirsize is greater >>> than NFS_MAXDGRAMDATA, it is possible for a thread doing an >>> I/O RPC to get stuck repeatedly doing retries. This happens >>> ... >> Could it wait for the old i/o to complete (and not start any new >> i/o?). This is little different from having to wait when changing >> from rw to ro. The latter is not easy, and at least the old nfs >> client seems to not even dream of it. ffs has always called a >> ... > As you said above "not easy ... uses complicated suspension of i/o". > I have not tried to code this, but I think it would be non-trivial. > The code would need to block new I/O before RPCs are issued and wait > for all in-progress I/Os to complete. At this time, the kernel RPC > handles the in-progress RPCs and NFS doesn't "know" what is > outstanding. Of course, code could be added to keep track of in-progress > I/O RPCs, but that would have to be written, as well. Hmm, this means that even when the i/o sizes are small, the mode switch from tcp to udp may be unsafe since there may still be i/o's with higher sizes outstanding. So to switch from tcp to udp, the user should first reduce the sizes, when wait a while before switching to udp. And what happens with retries after changing sizes up or down? Does it retry with the old sizes? Bruce