Date: Mon, 2 Mar 1998 00:59:57 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: help - make world fails Message-ID: <199803020059.RAA06455@usr04.primenet.com> In-Reply-To: <199803012350.PAA24569@implode.root.com> from "David Greenman" at Mar 1, 98 03:50:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >locking should go to a veto-based interface. My arguments for this are: > > > >o Common code > > > >o Locks go to vnode instead of in core inode > > > >o locks off vnode helps with stacking if VOP_FINALVP is > > implemented and used. This is pretty much a win for > > union and agregate FS's *only* > > > >o NFS client locks need to be remembered locally so that > > they can be reasserted in case of a server crash. This > > is my way of saving the state. > > > >o NFS wire traffic is reduced, if the lock conflict is > > between clients on the same machine (faster fail). > > > >o Ability to teat-and-not-set for multiplexing FS's (NFS > > is a mux for local vs. remote locks, and unionfs is a > > mux for local vs. local locks). > > As I see it, except for the last one on the list, the rest of the above > are not arguments in favor of "veto-based" advisory locking since they can > all be acheived without that. Agreed... it's an architectural issue, and as you are architect, I don't presume to make your decisions for you. You'll note that I haven't bitched about the locking code not being committed, and I've defended the non-commit at every turn, just to be clear where the line is... This is why I was very careful to point out the issues, hopefully without bias, towards my particular implementation. The list I provided is a bit biased, as far as I'm concerned; I think that I can't work on a soloution identical to USL's because of my history as a USL employee, without exposing the project to undue (IMO) legal risk. The only argument I have (besides the last item) is that the implementation detail skirts the USL non-disclosure issues that I personally have for me to do the work. It's a weak argument, I know, but at least I'm willing... I don't see the code coming from another source. Some people have suggested the USL approach (ie: new system call); I'm afraid I can't do the work in that case because of the conflict between my contractual obligation. I'm charting a narrow course, here, between prior art and things which I can't reasonably disclose, even if we all agree that there's nothing brilliant or fundamentally new there, even the fact that they have been disclosed before in "The Magic Garden Explained". If someone else can implement the other implementation details, I'd be fine with that approach (I really don't care, so long as the problem is resolved so I can build upon the resolution). Personally, I can't work on an implementation where rpc.lockd maintains local state. Right now, I'm (apparently) your best bet as someone willing to wade into this crap. I'm sure I agree with you that I wish this weren't so... 8-|. SunOS is the reference implementation for NFS locking, so there are worse thing than being interface compatible with SunOS, AFAICT. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803020059.RAA06455>