From owner-svn-src-all@FreeBSD.ORG Wed Jan 25 01:54:18 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 D01111065672; Wed, 25 Jan 2012 01:54:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9AA8FC14; Wed, 25 Jan 2012 01:54:18 +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 mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q0P1sEKR014423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 12:54:15 +1100 Date: Wed, 25 Jan 2012 12:54:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <201201250022.q0P0MsEY098760@svn.freebsd.org> Message-ID: <20120125121210.A1045@besplex.bde.org> References: <201201250022.q0P0MsEY098760@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org 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 01:54:18 -0000 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 > because the RPC will use a resize/wsize/readdirsize that won't > work for UDP and, as such, it will keep failing indefinitely. > This patch returns an error for this case, to avoid the problem. > A discussion on freebsd-fs@ seemed to indicate that returning > an error was preferable to silently ignoring the "udp"/"mntudp" > option. 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 flushfiles() function, but until relatively recently had lots of bugs in this area. It now uses complicated suspension of i/o to prevent starting new i/o. It is still the only file system in FreeBSD that uses MNTK_SUSPEND* or vfs_write_suspend(). (geom journal also uses vfs_write_suspend(), but I think it only works with ffs. vfs_write_suspend() uses MNT_SUSPEND in its call to VFS_SYNC(), but ffs_sync() is the only sync function that references MNT_SUSPEND.) I wonder how zfs handles this. > This problem was discovered while investigating a problem reported > by pjd@ via email. This problem has annoyed me for years. I now know a workaround :-). It doesn't help that, at least without nmount(), you can't see any of the udp/tcp, rsize or wsize parameters. The behaviour of mount -u should probably be to not change anything that is not an explicit parameter, but this is not traditional (mount -u traditionally means mount -u -o rw...) and is impossible for at least mount() to determine the current parameters, so it was passed a complete set of defaults. So for mount -u, you have to tell it all the current parameters that are not the default unless you want them changed back to the default, and it is just as impossible for you as for mount() to tell what the current parameters are. You have to remember what you set them to. When you forgot what they were or mistype type, you sometimes switch tcp back to udp when you meant to keep tcp, and see the bug. The rsize and wsize parameters give the additional problem that when switching between udp and tcp, the defaults for the size parameters change, so you normally don't want to keep the old parameters; but when testing which combination works best, you need to control the new parameters; in particular, it is useful to know what the defaults are; but the defaults are of course only documented in the source code, and the source code that sets the defaults is very large. Bruce