Date: Fri, 9 May 1997 10:32:17 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: sef@Kithrup.COM (Sean Eric Fagan) Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: PATCHES: NFS server locking support Message-ID: <199705091732.KAA00623@phaeton.artisoft.com> In-Reply-To: <199705090309.UAA04692@kithrup.com> from "Sean Eric Fagan" at May 8, 97 08:09:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > o The NAMEI layering changes > > o The namei() EXCLUDE flag changes > > 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. Unfortunately, I can't reasonably seperate them out of my source tree, yet proceed with other developement. My other developement is more important to me than spending the time to sterilize the changes. Free free to apply the inverse of the namei patch (the frozen NAMEI change patch), as suggested previously. As far as changing the API, I think that's exactly what needs to be done; it's been the fundamental basis of my FS arguments for years (that the current VOP/VFS layers were badly abstracted and not in concordance with the Heidemann documentation they purport to implement). > 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.) I give Jordan permission to repost my private email to him regarding the rpc.lockd enforcement model that these patches have in mind. It is identical to the model in the ISO documentation, and it is identical to the model employed by Sun Microsystems in SunOS 4.x, so it's not like it's "black art" or anything. Until POSIX semantic overrrides are in place, handles are converted to fd's, and the requests are made on the fd's. The fd's are lazy-closed (this is documented in the comments on the lf_unlksys() function) to avoid the POSIX crap. I suggest a handle hash and reference counting via dev/inode from fstat of the fd's. Alternately, Andrew, who wrote the original lockd, might be interested in doing the rest of the code. Just to chime in here: I'd like to see the same documentation for much of the FreeBSD kernel, especially the VM system. 8-). > > 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 ;)). Then you will also be concerned about what I did not document here: the lockf chain has been moved from the inode to the vnode; that's why it applies to all FS's equally now without additional local FS changes above the NFS/FFS changes to bring them in line with the new model. This will be obvious from even a cursory examination of the code, but I thought it would be best to prepare you. This necessitates a call to VOP_GETATTR() in the SEEK_SET case in order to get the file size. I viewed this as an acceptable trade (against a least-common case) that allowed me to abstract the advisory locking system away from the per FS in core inode object, and that's what makes advisory locking work on *ALL* FS's which return 0 from the FS specific VOP_ADVLOCK() (ie: they do not veto the lock request, and it is therefore committed). 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?199705091732.KAA00623>