From owner-freebsd-arch@FreeBSD.ORG  Sun Mar 15 21:07:53 2009
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id C0E791065676;
	Sun, 15 Mar 2009 21:07:53 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.freebsd.org (Postfix) with ESMTP id ADBB28FC1A;
	Sun, 15 Mar 2009 21:07:53 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id 9502F1A3C39; Sun, 15 Mar 2009 14:07:53 -0700 (PDT)
Date: Sun, 15 Mar 2009 14:07:53 -0700
From: Alfred Perlstein <alfred@freebsd.org>
To: Rick Macklem <rmacklem@uoguelph.ca>
Message-ID: <20090315210753.GX55200@elvis.mu.org>
References: <Pine.GSO.4.63.0903151520590.16993@muncher.cs.uoguelph.ca>
	<49BD6378.9030501@freebsd.org>
	<Pine.GSO.4.63.0903151654330.1646@muncher.cs.uoguelph.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.63.0903151654330.1646@muncher.cs.uoguelph.ca>
User-Agent: Mutt/1.4.2.3i
Cc: Tim Kientzle <kientzle@freebsd.org>, freebsd-arch@freebsd.org
Subject: Re: NFS version 4.0 for FreeBSD-CURRENT
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Mar 2009 21:07:54 -0000

* Rick Macklem <rmacklem@uoguelph.ca> [090315 13:57] wrote:
> 
> As far as the server goes, I'd have to look. NFSv4 locking
> doesn't use lockd, but my server does grab byte range locks
> through the VFS and I suspect lockd sees those, just like
> any other process sees them. (One advantage of NFSv4 is
> integrated locking that seems to work well.)

I think the way that kernel server NFS lockd works is that it sits
here:
V TCPIP
V lockd -> calls ASYNC locks down (expects callback)
V VFS -> calls back to lockd when locks are acquired

It's _not_ like this:
V TCPIP
V lockd -> calls SYNC locks down
V VFS 
V lockd -> stuff

so unless your server uses the async lock facility, you'll
wind up with your server context blocked in VFS waiting
for locks.

(I think.)

-Alfred