From owner-freebsd-current Wed Feb 25 20:49:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA11685 for freebsd-current-outgoing; Wed, 25 Feb 1998 20:49:42 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA11616 for ; Wed, 25 Feb 1998 20:49:22 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id VAA28947; Wed, 25 Feb 1998 21:49:15 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd028936; Wed Feb 25 21:49:10 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id VAA24670; Wed, 25 Feb 1998 21:49:07 -0700 (MST) From: Terry Lambert Message-Id: <199802260449.VAA24670@usr07.primenet.com> Subject: Re: Build still broken - NOT! - Oh yes it is (was) To: Matthew.Thyer@dsto.defence.gov.au (Matthew Thyer) Date: Thu, 26 Feb 1998 04:49:07 +0000 (GMT) Cc: perlsta@cs.sunyit.edu, current@FreeBSD.ORG In-Reply-To: <34F4DE2C.D51E404E@dsto.defence.gov.au> from "Matthew Thyer" at Feb 26, 98 01:44:52 pm 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The freebsd-current list has mentioned several times that there are > problems with both NFS client and server. I believe that Terry > recently made some changes to the NFS server code so maybe thats > not so bad. My changes are *only* in support of NFS locking, and still require RPC client calls in the kernel for NFS clients, and rpc.statd and rpc.lockd changes in user space for NFS servers. They assert the client locks locally (in a pre-coelesced state), in case the proxy assertion by the FreeBSD NFS client to the remote server fails, so they can be backed out without destroying state. A side effect of this is reduced wire traffic on a local conflict (assuming the client RPC calls were actually being made), but the main reason is so the NFS client can reassert the locks correctly after an NFS server restarts (rpc.statd needs to tell the client about the reboot). The local assertion would have the effect of making NFS client locking work, but only intra-client, not inter-client. In any case, these changes have not been committed, despite the fact that they have been run without incident by many people for two weeks now. That means other people can't start on the rpc calling/serving code without a hacked and officially unsanctified kernel. 8-(. > I read the cvs-all and freebsd-current list and am waiting for > a mega commit that fixes NFS! - I'm not holding my breath though 8-) Other NFS fixes from me (other than trivial onces that I'm sure will be commited) will have to wait until it's even possible for me to go through the thing with a fine-tooth-comb. That's not possible right now, given the way it's organized, and I'd really hesitate to add more hack-on-a-hack type "fixes" until I can remove the quotes from "fixes". 8-(. > Possibly some of the problems I have seen (corruption of files) are > related to the recent VM instability which seems to be almost fixed, > so maybe I should try another NFS mounted make world. Some of the problems are from here. Not all of them, and not the big ones that are really biting you (IMO; others may differ, and if so, I will be happy to seem them commit their fixes). 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-current" in the body of the message