Date: Sun, 1 Mar 1998 23:17:00 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: karl@mcs.net (Karl Denninger) Cc: eivind@yes.no, hackers@FreeBSD.ORG Subject: Re: help - make world fails Message-ID: <199803012317.QAA04517@usr08.primenet.com> In-Reply-To: <19980301095616.35833@mcs.net> from "Karl Denninger" at Mar 1, 98 09:56:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Well, that's not good enough. Terry's patches haven't been committed, and > there has to be a reason for that. My NFS patches being discussed don't do anything other than locks. There is an architectural issue here as to whether or not the advisory 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). I think they are overwhelming, but I may be biased, having written the code. ;-). This is a style decision that I have not been persuasive enough about yet. That the code is "there" is not enough, probably because the rpc.lockd and rpc.statd code has not been completed and/or the client RPC code has not been completed. I'm wary of doing either of these before the infrastructure is committed because of mega-commit-phobia. > I HATE off-stream things. I have to deal with some of them all the time, > because we have some local ones (to do our funny clustering and kernel-based > permission masking, to name two). That's enough of a pain in the ass to > track across multiple revisions. If they were committed, they would not fix your client problems, unless your problems were lock-related. If your problems *were* lock related, they would *apparently* fix them, if you only test between clients on the same machine, until the other code goes in as well. Most likely, your client problems are *not* lock related, so for you, the patches being integrated would be a NOP. 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?199803012317.QAA04517>