Date: Tue, 1 Jul 1997 10:09:45 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: lederer@bonn-online.com (Sebastian Lederer) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: NFS V3 is it stable? Message-ID: <199707011709.KAA18598@phaeton.artisoft.com> In-Reply-To: <33B89142.41C67EA6@bonn-online.com> from "Sebastian Lederer" at Jul 1, 97 07:10:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. :) > > What would be the requirements for this ? It does not seem too > complicated to me, at least the rpc.lockd framework is already in place. > So the "only" thing left to do would be to manage lists of locks from a > set of hosts and processes, probably merging adjacent locks etc, and > using the F_RSETLK fcntls to actually set the locks in the kernel. > Probably the interaction with rpc.statd would also need some attention. > Or am I grossly missing something? See my other posting; but basically the big obstacles are: 1) The POSIX semantics make it difficult for rpc.lockd to have only one file handle per file regardless of the number of clients with the file open. This is a bit of a pain to overcome, and requires a semantic override. 2) The assertion of a lock can not immediately result in a coelesce if the operation may be backed out. But the assertion must have the force of having already been coelesced for the purposes of denying subsequent lock requests before the server has completed the initial request. 3) The interface must be veto based, so that it is possible to have both local and remote assertion. This is a requirement for client locking, both for preemptive denial as an optimization to save wire traffic, AND to allow the client to recover lock state in the event of a transient server failure (ie: the server is rebooted, etc.). 4) So that server locking works on all file systems, the lock list must be hung off the vnode instead of the inode; one consequence of this is that it drastically simplifies the locking code, and makes it general to all FS's, instead of per FS. As it currently stands, there are FS's on which locking will fail (ie: MSDOSFS, ISOFS, etc.). > If not, then I could probably spend some time to work on this, if nobody > else is already doing it. Doug Rabson has the kernel patches for everything, minus the handle conversion call, and minus the POSIX semantic override. There *IS* a bug in the namei() code, which I was able to test everywhere but the NFS client (I only have one FreeBSD box at this location). If you are interested in helping locate this bug, I can send you a test framework for kernel memory leak detection, and my test set for the namei() buffers, specifically. 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?199707011709.KAA18598>