Date: Thu, 8 May 1997 18:27:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hackers@freebsd.org, current@freebsd.org Subject: PATCHES: NFS server locking support Message-ID: <199705090127.SAA29328@phaeton.artisoft.com>
next in thread | raw e-mail | index | archive | help
I have just uploaded patches for kernel support of NFS server locking. They are on freefall in the file: ~terry/LOCK.DIFF This file contains: o The NAMEI layering changes o The namei() EXCLUDE flag changes Note: If you don't like this, fix CVS, or apply the inverse of the NAMEI patch, which is located in: ~terry/NAMEI.DIFF.FREEZE Otherwise, I think this should be committed as a unit. o The necessary changes to the fcntl(2) man page o Support for the additional fcntl(2) operands: F_RGETLK Remote Get lock F_RSETLK Remote set lock F_RSETLKW Remote set lock, blocking * F_CNVT Convert NFS handle to open fd o Support for the additional record locking flag: ** F_UNLKSYS Remove all locks for a given system id o Veto restructuring changes to VOP_ADVLOCK and the FS specific VOP_ADVLOCK code, as necessary to implement reversible local lock assertion in the case of an NFS client lock failure. As a side effect, advisory file and record locking now works on all file systems, not just FFS and NFS. 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. 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. ** 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. This file does *NOT* contain: o Patches to rpc.lockd to make it anything other than the stub server it currently is. o NFS client locking code in nfs/nfs_vnops.c o Necessary POSIX semantic overides on close(2) interaction with advisory locks for multiple open fd's referencing the same file. o Mandatory locking support for Solaris ABI compatavbility (it's relatively trivial, but would complicate testing). What I am intereted in: o If anyone can panic the code. o If this breaks any locking applications. It seems to pass POSIX validation on my local system, but I would be interested in more complex multi-process locking tests which exercise the proxy facilities in addition to the local locking semantics. I would be interested in deadlock and collision/embrace case tests, if anyone is interested in writing them. o I'd like to see this code committed, assuming it doesn't break anything, including the namei changes. I think the additional functionality added to all FS's instead of just NFS an FFS proves the merits of correcting the layering, as well as the merits of veto-based processing. o I'd like to see someone flesh out the rpc.lockd, like Jordan promised to do for his BSD internals class. If the code is committed so that I don't have to maintain it locally, I'd be happy to work on rpc.lockd with the time saved. o NetBSD/OpenBSD/BSDi picking up this code. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705090127.SAA29328>