From owner-freebsd-stable@FreeBSD.ORG Thu Jan 6 15:09:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6899910656D6 for ; Thu, 6 Jan 2011 15:09:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 396988FC0C for ; Thu, 6 Jan 2011 15:09:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E3D8546B58; Thu, 6 Jan 2011 10:09:08 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DD9068A01D; Thu, 6 Jan 2011 10:09:07 -0500 (EST) From: John Baldwin To: perryh@pluto.rain.com Date: Thu, 6 Jan 2011 08:04:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <1036681015.111502.1294189339355.JavaMail.root@erie.cs.uoguelph.ca> <201101050757.08116.jhb@freebsd.org> <4d257864.YjgoS235V8eKvUX2%perryh@pluto.rain.com> In-Reply-To: <4d257864.YjgoS235V8eKvUX2%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101060804.56205.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 06 Jan 2011 10:09:08 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: marek_sal@wp.pl, freebsd-stable@freebsd.org, jyavenard@gmail.com, rmacklem@uoguelph.ca, milu@dat.pl Subject: Re: NFSv4 - how to set up at FreeBSD 8.1 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:09:09 -0000 On Thursday, January 06, 2011 3:08:04 am perryh@pluto.rain.com wrote: > John Baldwin wrote: > > > ... even NFS UDP mounts maintain their own set of "socket" state > > to manage retries and retransmits for UDP RPCs. > > Not according to what I remember of the SunOS NFS documentation, > which indicated that the driving force behind using UDP instead of > TCP was to have the server be _completely_ stateless. (Of course > locking is inherently stateful; they made it very clear that the > locking protocol was considered to be an adjunct rather than part > of the NFS protocol itself.) No extra NFS state is tied to a TCP mount aside from maintaining TCP state (i.e. congestion window for the socket, etc.). A TCP mount does not have a different amount of NFS state than a UDP mount. As Rick noted, many servers do maintain a DRPC, but that applies to both UDP and TCP mounts. > It's been quite a few years since I read that, and I didn't get > into the details, but I suppose the handle returned to a client (in > response to a mount or open request) must have contained both a > representation of the inode number and a unique identification of > the filesystem (so that, in the case where server crash recovery > included a newfs and reload from backup, the FS ID would not match > and the client would get a "stale handle" response). All of the > retry and retransmit burden had to have been managed by the client, > for both reading and writing. Yes, this is true for both UDP and TCP (if you exclude TCP's retransmit for missed packets in server replies on a TCP mount). Even with TCP a client can still retransmit requests for which it does not receive a reply in case the connection dies due to a network problem, server reboot, etc. -- John Baldwin