From owner-freebsd-hackers Mon May 12 03:55:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA12018 for hackers-outgoing; Mon, 12 May 1997 03:55:49 -0700 (PDT) Received: from monorail.net-tel.co.uk (monorail.net-tel.co.uk [193.122.171.247]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA11980; Mon, 12 May 1997 03:55:38 -0700 (PDT) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by monorail.net-tel.co.uk (8.8.4/8.8.4) id LAA04954; Mon, 12 May 1997 11:53:06 +0100 (BST) Received: from "/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/" by net-tel.co.uk (Route400-RFCGate); Mon, 12 May 97 10:49:37 +0000 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Mon, 12 May 97 10:49:37 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Mon, 12 May 97 10:49:36 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:74-970512104936-6892] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Mon, 12 May 97 10:49:36 +0000 X400-Content-Identifier: Re: PATCHES: NFS Message-Id: <"710-970512105050-E04B*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: terry@lambert.org Cc: hackers@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199705090127.SAA29328@phaeton.artisoft.com> Subject: Re: PATCHES: NFS server locking support Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > * 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).