From owner-freebsd-stable@FreeBSD.ORG Thu Jan 6 13:18:12 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 2B15A1065679; Thu, 6 Jan 2011 13:18:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id CB6848FC18; Thu, 6 Jan 2011 13:18:11 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAGAF9PJU2DaFvO/2dsb2JhbACDd5ITjwKwCI1YgSGDN3QEhGc8hWY X-IronPort-AV: E=Sophos;i="4.60,283,1291611600"; d="scan'208";a="104448547" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 06 Jan 2011 08:18:11 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1F167B3F6B; Thu, 6 Jan 2011 08:18:11 -0500 (EST) Date: Thu, 6 Jan 2011 08:18:11 -0500 (EST) From: Rick Macklem To: perryh@pluto.rain.com Message-ID: <1634633777.173061.1294319891074.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4d257864.YjgoS235V8eKvUX2%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: marek sal , freebsd-stable@freebsd.org, milu@dat.pl, jyavenard@gmail.com, jhb@freebsd.org 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 13:18:12 -0000 > 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.) > For UDP, in the server all requests show up at socket/port 2049. They pretty quickly discovered that retries of non-idempotent RPCs trashed things, so the Duplicate Request Cache was invented, which is really state that doesn't have to be recovered after a server crash. (By Chet Jacuzak at DEC, if I recall correctly, who is living on a little island on a lake up in Maine, last I heard.) My recollection of why Sun didn't use TCP was that "they knew that the overhead would be excessive", which wasn't completely untrue, given the speed of an MC68020. > 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. Yea, it depended on how the backup was done. To avoid "stale handle" the backup/reload had to retain the same i-nodes, including the generation number in them. (But, then, those 1980s SMD disks never trashed the file systems, or did they?:-) You shouldn't get me reminising on the good ole days, rick