Date: Tue, 1 Jul 1997 09:58:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: witr@rwwa.com, chuckr@glue.umd.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: NFS V3 is it stable? Message-ID: <199707011658.JAA18573@phaeton.artisoft.com> In-Reply-To: <24401.867727961@time.cdrom.com> from "Jordan K. Hubbard" at Jun 30, 97 08:32:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> We've been waiting forever for someone to take an active enough interest > in this to implement an NFS locking daemon. We're still waiting. ;) > > Jordan > > P.S. Terry sent me the skeleton of something way back when I was > actually masochistically considering this myself, but I came to > my senses and backed away in time. :) The rpc.lockd stuff is nothing more than grunt-work, actually, after the SunOS 4.1.3 compatible fcntl() calls are implemented. The big problem that BSD4.4-Lite2 introduced is the POSIX semantics for a single close removing all locks. If you seperate this into a veto interface, it's fairly trivial to implement things such that server locking is supported and client locking is not actively prevented by the locking architecture. My current problem is that I can't do the NFS testing locally. I sent Doug Rabson my kernel memory leak test framework, and in combination with other patches, I've introduced a small namei() buffer leak into the NFS code, which is localizable by VOP using the test framework. I think this has to do with the NFSv3 lookup changes. The big magic is to make VOP_ADVLOCK return 0 to accept or an errno.h value to veto a given lock. Then the locking is seperated into: assert check veto coelesce ...in other words, the coeslesce is delayed. This has to be done because of the side effects of locking from the client to the server means that the lock must be asserted on both ends to preserve semantics, but if either end fails the lock, then both ends must be backed out. Obviously, it's impossible to back out a lock that has been coelesced with another lock, without potentially damaging the existing lock; this is especially true if the lock represents a type promotion or demotion between read/write locking. The veto is done on the client rather than on the server because: 1) It is useful to be able to deny some locks without generating a wire delay in order to do it. 2) A wire-based veto would require a change to the NFS locking protocol as defined in the ISO standard, which would make it non-interoperable with all other NFS locking interfaces. 3) In the event of a server failure, the client lock state is recoverable when the server comes back up (this is also the reson the lock must be asserted on both the client and the server). I can go over rpc.lock fd conservation and handle conversion in the face of POSIX close semantics, if anyone is interested in doing the user space code; as I said before, once you understand the issues, the code is trivial: just grunt work, nothing more. 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?199707011658.JAA18573>