Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 May 97 10:49:36 +0000
Cc:        hackers@FreeBSD.ORG, current@FreeBSD.ORG
Subject:   Re: PATCHES: NFS server locking support
Message-ID:  <"710-970512105050-E04B*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS>
In-Reply-To: <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> *               F_CNVT          Convert NFS handle to open fd
> Notes:  *       F_CNVT requires a covenant between the NFS lockd in
>                 user space, and the kernel, based on the wire
>                 representation of NFS file handles propagated to
>                 the lockd process.  Because I don't know what this
>                 is from the incomplete user space rpc.lockd code,
>                 this function is stubbed to return ENOSYS.  Once
>                 this information is documented, it will be a simple
>                 matter to call FHTOVP on the user's behalf.

It's not documented in the spec either!  There is a bit of clarification
in the NFS V3 spec (which sadly documents only the delta from old
locking to new locking, rather than re-specifying the whole thing):

  "in the NLM version 3 protocol, the file handle is a fixed-length NFS
   version 2 file handle, which is encoded as a byte count followed by
   a byte array.  In the NFS version 3 protocol, the file handle is
   already variable length, so it is copied directly into the _fh_ field.
   That is, the first four bytes of the _fh_ field are the same as the 
   byte count in an NFS version 3 protocol _nfs_fh3_.  The rest of the
   _fh_ field contains the byte array from the NFS version 3 protocol

[Note for added confusion that the locking protcol for NFS v2 is NLM v3,
and the locking protocol for NFS v3 is NLM v4 !].

I found, last time I looked at this, that the encoding for NFS v2 was
fairly obvious when you looked at a trace of existing implementations
talking to each other; however, I don't have a pair of third-party
NFS v3 implementations available to check. 

>                 Note that POSIX close semantics regarding advisory
>                 locking are antagonistic to an NFS lockd at this
>                 time.  I have not written a POSIX namespace override
>                 option for open or for fcntl() at this time.  This
>                 means the user space NFS lockd will not be able to
>                 coelesce open fd's, and must lazy-close them based
>                 on stat information.  This will severely restrict
>                 the number of simultaneous locking clients that can
>                 ne active at one time until these semantic overrides
>                 go in.

I don't see why the POSIX close semantics are a problem here - I would
expect the lockd to hold only one open fd for each file handle (with the
owner/pid fields in the lock distinguishing individual clients).
Of course, the limit on open fds per process is potentially limiting
on a single-process lockd, but there is no obvious way round this.

>         **      The F_UNLKSYS function operates on a single process
>                 open file table.  This means that you can not have
>                 peer-based load balancing of NFS lockd clients.  This
>                 could be rewritten to travers the system open file
>                 table instead of the per process open file table.  If
>                 this were done, the restriction would be lifted.  I
>                 am personally more interested in a multithreaded NFS
>                 lockd instead of a multiple instances of an NFS lockd,
>                 so I have not done this.

Is this how you plan to handle blocking locks?  The one thing that you
don't appear to have provided is a mechanism for waking up the lockd when
a previously unavailable lock becomes free (so that lockd can inform the
client).  If the lockd is multi-threaded to the extent that it can afford
to have one of its threads go into a blocking fcntl() call for each
outstanding lock, then this requirement goes away - but that assumes
kernel threads, and also presents a problem for implementation of the
nlm_cancel from the client (which cancels a previous blocking lock request). 

Want to link to this message? Use this URL: <"710-970512105050-E04B*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/">