Date: Sun, 15 Mar 2009 14:07:53 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Tim Kientzle <kientzle@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: NFS version 4.0 for FreeBSD-CURRENT Message-ID: <20090315210753.GX55200@elvis.mu.org> In-Reply-To: <Pine.GSO.4.63.0903151654330.1646@muncher.cs.uoguelph.ca> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090315210753.GX55200>