From owner-freebsd-stable@FreeBSD.ORG Wed Jan 5 13:43:51 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 35EA51065670 for ; Wed, 5 Jan 2011 13:43:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E7E638FC0A for ; Wed, 5 Jan 2011 13:43:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GAKoEJE2DaFvO/2dsb2JhbACDeJIbjwexBI4QgSGDN3QEhGiGIg X-IronPort-AV: E=Sophos;i="4.60,278,1291611600"; d="scan'208";a="105973300" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Jan 2011 08:43:50 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 25AB5B3F0F; Wed, 5 Jan 2011 08:43:50 -0500 (EST) Date: Wed, 5 Jan 2011 08:43:50 -0500 (EST) From: Rick Macklem To: perryh@pluto.rain.com Message-ID: <1229754447.119764.1294235030140.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4d244e39.KoPcOoMaWed+H5De%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 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: Wed, 05 Jan 2011 13:43:51 -0000 > Rick Macklem wrote: > > > ... one of the fundamental principals for NFSv2, 3 was a stateless > > server ... > > Only as long as UDP transport was used. Any NFS implementation that > used TCP for transport had thereby abandoned the stateless server > principle, since a TCP connection itself requires that state be > maintained on both ends. > You've seen the responses w.r.t. what stateless server referred to already. But you might find this "quirk" interesting... Early in the NFSv4 design, I suggested that handling of the server state (opens/locks/...) might be tied to the TCP connections (NFSv4 doesn't use UDP). Lets just say the idea "flew like a lead balloon". Lots of responses along the lines of "NFS should be separate for the RPC transport layer, etc. Then, several years later, they came up with Sessions for NFSv4.1, which does RPC transport management in a very NFSv4.1-specific way, including stuff like changing the RPC semantics to exactly-once... Although very different from what I had envisioned, in a sense Sessions does tie state handling (ordering of locking operations, for example) to RPC transport management as I currently understand it. rick