From owner-freebsd-hackers Sun Mar 1 15:17:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA20865 for freebsd-hackers-outgoing; Sun, 1 Mar 1998 15:17:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA20850 for ; Sun, 1 Mar 1998 15:17:12 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA03978; Sun, 1 Mar 1998 16:17:08 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd003946; Sun Mar 1 16:17:03 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA04517; Sun, 1 Mar 1998 16:17:00 -0700 (MST) From: Terry Lambert Message-Id: <199803012317.QAA04517@usr08.primenet.com> Subject: Re: help - make world fails To: karl@mcs.net (Karl Denninger) Date: Sun, 1 Mar 1998 23:17:00 +0000 (GMT) Cc: eivind@yes.no, hackers@FreeBSD.ORG In-Reply-To: <19980301095616.35833@mcs.net> from "Karl Denninger" at Mar 1, 98 09:56:16 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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