From owner-freebsd-stable@FreeBSD.ORG Thu Jan 6 12:59: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 932931065695; Thu, 6 Jan 2011 12:59:09 +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 3F1698FC12; Thu, 6 Jan 2011 12:59:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAGANtLJU2DaFvO/2dsb2JhbACDd5ISjwKwBY1ZgSGDN3QEhGeGIg X-IronPort-AV: E=Sophos;i="4.60,283,1291611600"; d="scan'208";a="104446800" 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 07:58:55 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3FD1D793A7; Thu, 6 Jan 2011 07:58:55 -0500 (EST) Date: Thu, 6 Jan 2011 07:58:55 -0500 (EST) From: Rick Macklem To: perryh@pluto.rain.com Message-ID: <1301662185.172571.1294318735174.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4d258100.Wu9WZrgdH2/KvDTa%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.202] 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 12:59:09 -0000 > Rick Macklem wrote: > > > Sun did add a separate file locking protocol called the NLM > > or rpc.lockd if you prefer, but that protocol design was > > fundamentally flawed imho and, as such, using it is in the > > "your mileage may vary" category. > > I suppose it was not all that bad, considering that what it sought > to accomplish is incomputable. There is simply no way for either > the server or the client to distinguish between "the other end has > crashed" and "there is a temporary communication failure" until the > other end comes back up or communication is restored. > Yep. The blocking lock operation is also a trainwreck looking for a place to happen, imho. (In the NLM, the client can do an RPC that says "get a lock, waiting as long as necessary for it, and then let me know".) > On a good day, in a completely homogeneous environment (server and > all clients running the same OS revision and patchlevel), I trust > lockd about as far as I can throw 10GB of 1980's SMD disk drives :) > Heh, heh. For those too young to have had the priviledge, a 1980s SMD drive was big and HEAVY. I just about got a hernia every time one had to go in a 19inch rack. You definitely didn't throw them far:-) > Exporting /var/spool/mail read/write tends to ensure that good days > will be rare. Been there, done that, seen the result. Never again. > That's what IMAP is for. > Great post. I couldn't have said it as well, rick