Date: Mon, 12 May 97 10:49:36 +0000 From: Andrew.Gordon@net-tel.co.uk To: terry@lambert.org 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: <199705090127.SAA29328@phaeton.artisoft.com>
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 _nfs_fh3_." [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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?"710-970512105050-E04B*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/">