Kernel support for NFS locking (was: Re: rpc.lockd spinning; much breakage)

[Andrew P. Lentvorski, Jr.]

On Tue, 13 May 2003, Robert Watson wrote:

> > Andrew P. Lentvorski wrote:
> >
> > One problem is that FreeBSD doesn't allocate enough fields in its local
> > lock structure to distinguish external identifiers in the locks (all
> > locks look like they are owned by the rpc.lockd user).  Consequently,
> > rpc.lockd has to maintain its own state as to who has what locks.
> 
> If this isn't a user/kernel ABI/API problem, it should be easily solvable,
> and we should do that following 5.1-RELEASE.

This opens up a several cans of worms:

1) Is this going to suck down too much memory?  rpc.lockd identifiers can 
        be really long

2) Should the kernel have some mechanism for handling locking
	Notifiying processes which are waiting for a blocked lock is more 
	efficient as a kernel callback rather than process polling.  Is 
	kqueue/kevent sufficient?

3) Should the kernel have some mechanism for modular handling of locking 
	associated with an FS?  ie. the ability to pass out NFS locks on
	say an SMB mounted FS

4) Should duct tape be the solution to NFSv2 and NFSv3 and folks should 
	just move to NFSv4?

5) What is the status of NFSv4?

6) What other FS's need adjustments to the FreeBSD file lock strcutures?

I'm certainly not qualified to answer these questions, so I'm going to 
transfer this message over to fs at freebsd.org in the hope that someone 
better qualified can provide more insight.

-a