rpc.lockd spinning; much breakage

[Robert Watson]

On Tue, 13 May 2003, Andrew P. Lentvorski, Jr. wrote:

> On Mon, 12 May 2003, Robert Watson wrote:
> 
> > (3) Sometimes rpc.lockd on 5.x acting as a server gets really confused
> >     when you mix local and remote locks.
> 
> Yes, don't do that. ;) 

Unfortunately, a common case I'm interested in is "mail spool on a mail
server is NFS-exported to many clients", which bumps into locking between
the client and server pretty quickly :-).

> 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.

> I believe there were also some issues with atomicity in POSIX partial
> file locking on FreeBSD that have since been fixed. 
> 
> Consequently, I punted when I wrote the rpc.lockd code to support POSIX
> partial file locking.  The server rpc.lockd locks the *entire file* when
> it gets an NFS request to lock any portion of it.  In addition, it will
> return an immediate fail if the kernel has any portion of the desired
> file locked. 

This sounds like a reasonable work-around given that the common case is
currently whole-file locking; we just need to make sure that the semantics
are exposed properly to the application.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories