From owner-freebsd-hackers Mon Jun 30 22:11:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA08996 for hackers-outgoing; Mon, 30 Jun 1997 22:11:02 -0700 (PDT) Received: from circe.bonn-online.com (root@circe.bonn-online.com [195.52.214.66]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA08990 for ; Mon, 30 Jun 1997 22:10:57 -0700 (PDT) Received: from rain (portC7.bonn-online.com [195.52.214.78]) by circe.bonn-online.com (8.8.5/8.8.5) with SMTP id HAA08089 for ; Tue, 1 Jul 1997 07:10:38 +0200 Message-ID: <33B89142.41C67EA6@bonn-online.com> Date: Tue, 01 Jul 1997 07:10:26 +0200 From: Sebastian Lederer X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2-961014-SNAP i386) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: NFS V3 is it stable? References: <24401.867727961@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > > But... I am doing this without *any* problems with FBSD 2.1.[567], where the > > mail spools are served by a Solaris system. I was going to upgrade > > a bunch of systems to 2.2-release, but now I'm worried. IMO, This *must* > > be made to work at least as well as it does in 2.1.[567]. > > It never worked at all, not in 2.1.[67] or now, so your degree of risk > is essentially the same. > > We've been waiting forever for someone to take an active enough interest > in this to implement an NFS locking daemon. We're still waiting. ;) > > Jordan > > P.S. Terry sent me the skeleton of something way back when I was > actually masochistically considering this myself, but I came to > my senses and backed away in time. :) What would be the requirements for this ? It does not seem too complicated to me, at least the rpc.lockd framework is already in place. So the "only" thing left to do would be to manage lists of locks from a set of hosts and processes, probably merging adjacent locks etc, and using the F_RSETLK fcntls to actually set the locks in the kernel. Probably the interaction with rpc.statd would also need some attention. Or am I grossly missing something? If not, then I could probably spend some time to work on this, if nobody else is already doing it.