Date: Thu, 8 May 1997 20:09:15 -0700 From: Sean Eric Fagan <sef@Kithrup.COM> To: current@freebsd.org Subject: Re: PATCHES: NFS server locking support Message-ID: <199705090309.UAA04692@kithrup.com> In-Reply-To: <199705090127.SAA29328.kithrup.freebsd.current@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199705090127.SAA29328.kithrup.freebsd.current@phaeton.artisoft.com> terry writes: >I have just uploaded patches for kernel support of NFS server locking. I've looked at a previous version of these patches before (and am going over the current ones now). > 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. I am still, as I have told Terry, not sure about these changes. I don't object to them in principal (and, for what they want to do, the code looks correct, based on my manual examination), but they are a change in the API, and that bothers me. > o The necessary changes to the fcntl(2) man page > o Support for the additional fcntl(2) operands: [...] >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. While I think this is a nice thing, and the code seems okay (I wonder about the "backward compatibility hack" though). However... I would prefer to see some explanation of the programming model (although it's pretty easy to figure out, I think, based on the code) *AND* a working lockd. (But, again: not a terribly strong requirement, as long as lockd is being worked on. But without it, these changes do nothing, which means just another source of potential bitrot.) >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 See my above comment about these. >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. However, these are very worthwhile reasons to try this out. I assume Terry has done all the testing he thinks he's able to do, and wants to get it out to a wider audience. (Although, speaking from personal experience, this is always a terribly frustrating thing to do while developing code. *sigh* Unfortunately, since I don't do much with locking, and nothing with NFS, I'm not a good test subject, so I can't volunteer for that. Sorry.) > 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. The namei changes to concern me. The other people working on filesystem code *MUST* buy into this. If they're willing to do the changes, I don't object (if anyone really cares, I mean ;)). Sean.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705090309.UAA04692>