Re: nfs server performance (netbsd-5)

[christos%astron.com@localhost (Christos Zoulas)]

In article <315A9178-6A6F-4154-BB9E-90BC7D29FA1E%zhadum.org.uk@localhost>,
Matthias Scheler  <tron%zhadum.org.uk@localhost> wrote:
>
>On 24 Apr 2010, at 1:02, Aaron J. Grier wrote:
>> I have also been seeing aborted builds of NetBSD-5 from a NetBSD-5
>> machine NFS mounting sources from a NetBSD-3 machine:
>> 
>> /amd/SERVER/usr/projects/NetBSD/5/src/sys/sys/uio.h:99:27: error:
>/amd/SERVER/usr/projects/NetBSD/5/src/sys/../common/include/sys/mallocvar.h:
>Device busy
>> 
>> I don't know if it's related or not, or if I'm the only person seeing
>> this.  it's too bad there's nobody for GSoC to go spelunking in the NFS
>> code.  ;)
>
>1.) This is (at least very likely) not a problem in the kernel
>    NFS code but a problem in the automounter daemon.
>
>2.) You are not the only one seeing this:
>
>       http://gnats.netbsd.org/41259
>
>3.) I proposed a Google Summer of Code project to get this fixed:
>
>       http://mail-index.netbsd.org/tech-net/2010/04/06/msg002004.html

Solution 2 does not work because there are always race conditions
when you mount and access things from userland. This is what autofs
is trying to solve. The automounter is a userspace application
already; it pretends to be an NFS server for all the "auto"
directories it manages and then handles accesses in those directories
by doing the appropriate symlink and mounting. The problem is that
it forks in order to do things in parallel and non blocking form,
and one child can race with another child undoing what the first
child does. While things are in flux, other processes see an
inconsistent view of the world.

christos