From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 15:46:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E10B16A420 for ; Mon, 27 Feb 2006 15:46:58 +0000 (GMT) (envelope-from danny@g-mapps.com) Received: from valium.tcm.gmapps.net.uk (valium.tcm.gmapps.net.uk [194.207.235.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3160943D49 for ; Mon, 27 Feb 2006 15:46:57 +0000 (GMT) (envelope-from danny@g-mapps.com) Received: from [62.24.226.220] ([62.24.226.220]) (authenticated bits=0) by valium.tcm.gmapps.net.uk (8.13.4/8.13.3) with ESMTP id k1RFoNMW020951; Mon, 27 Feb 2006 15:50:23 GMT (envelope-from danny@g-mapps.com) Message-ID: <44031EE3.3080407@g-mapps.com> Date: Mon, 27 Feb 2006 15:46:43 +0000 From: Danny Butroyd User-Agent: Thunderbird 1.5 (X11/20060123) MIME-Version: 1.0 To: Mike Tancsa References: <4402F009.1000407@g-mapps.com> <6.2.3.4.0.20060227093542.086c56c0@64.7.153.2> <44031194.8000300@g-mapps.com> <6.2.3.4.0.20060227095704.085300c8@64.7.153.2> <44031A0E.9060402@g-mapps.com> <6.2.3.4.0.20060227102902.08d08268@64.7.153.2> In-Reply-To: <6.2.3.4.0.20060227102902.08d08268@64.7.153.2> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on valium.tcm.gmapps.net.uk X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: nfs woes in FreeBSD 6.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 15:46:58 -0000 Mike Tancsa wrote: > At 10:26 AM 27/02/2006, Danny Butroyd wrote: > >> OK, do the changes affect both server and client and is there any >> documentation on the changes? > > cvs commits and reading this mailing is the best place to track what has > changed in detail. Unfortunately, there is no middle ground source for > information. I use a procmail script to sort all RELENG_6 commits into > a file that I can then search through after the fact. The descriptions > generally offer an OK description as to what was changed / fixed > improved. If that fails, going back to the original commit message might > offer more detail. e.g. a quick perusal of just the nfs code commits > shows a couple of obvious bug fixes. > > > maxim 2005-12-15 18:10:37 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_6) > sys/nfsclient nfs_socket.c > Log: > MFC rev. 1.134: fix for a bug where NFS/TCP would > not reconnect (in the case where the server FIN'ed). > > PR: kern/88833 > Requested by: Roman V. Palagin > Approved by: Mohan Strinivasan > > Revision Changes Path > 1.125.2.5 +1 -1 src/sys/nfsclient/nfs_socket.c > > > > tegge 2006-01-14 01:05:22 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_6) > sys/nfs4client nfs4_vfsops.c > Log: > MFC: Obtain mount point lock before restarting sync loop if vget() > failed. > > Revision Changes Path > 1.20.2.1 +1 -0 src/sys/nfs4client/nfs4_vfsops.c > > > > rwatson 2006-02-14 00:06:32 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_6) > sys/nfsclient nfs_lock.c > Log: > Merge nfs_lock.c:1.43 from HEAD to RELENG_6: > > In nfs_dolock(), GC now under-used ioflg, rendered obsolete when we > moved > from using a fifo to talk to rpc.lockd to using a special device node. > > Approved by: re (scottl) > > > > > rees 2006-02-16 02:39:53 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_6) > sys/nfsclient nfs_socket.c > Log: > MFC rev 1.135: > Don't log an error on tcp connection reset, even if we don't get > ECONNRESET. > > Submitted by: cel@citi.umich.edu > Approved by: re (scottl) > > Revision Changes Path > 1.125.2.6 +2 -2 src/sys/nfsclient/nfs_socket.c Thanks for the info Mike, I will upgrade my client machine to 6.1 (as the changes appear to be for the client source code) and do some testing. Cheers Danny > > > > > >> > >> > BTW, if you are using tcp mounts, and you have devices not on the same >> > subnet, setting >> > net.inet.tcp.inflight.enable=0 >> > helps with performance. However, this is a separate issue to the >> > problems you are seeing. >> > >> Yeah, I saw this in the list archives :) >> >> Danny >> > ---Mike >> > >> > >> >> Danny >> > >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" >> > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >