From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 03:43:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 995EE16A4CE for ; Wed, 13 Oct 2004 03:43:19 +0000 (GMT) Received: from corbulon.video-collage.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D38143D1D for ; Wed, 13 Oct 2004 03:43:18 +0000 (GMT) (envelope-from Mikhail.Teterin@murex.com) Received: from 250-217.customer.cloud9.net (195-11.customer.cloud9.net [168.100.195.11])i9D3etno057896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Oct 2004 23:40:56 -0400 (EDT) (envelope-from Mikhail.Teterin@murex.com) Received: from [127.0.0.1] (mteterin@localhost [127.0.0.1]) i9CIe2AQ031937; Tue, 12 Oct 2004 14:40:02 -0400 (EDT) (envelope-from Mikhail.Teterin@murex.com) Message-ID: <416C2502.5040505@murex.com> Date: Tue, 12 Oct 2004 14:40:02 -0400 From: Mikhail Teterin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; uk-UA; rv:1.7.2) Gecko/20041006 X-Accept-Language: uk, en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <416AE7D7.3030502@murex.com> <200410112038.i9BKcCWt051290@apollo.backplane.com> <416C1B10.7030103@murex.com> <200410121818.i9CIIGRx092072@apollo.backplane.com> In-Reply-To: <200410121818.i9CIIGRx092072@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version devel-20040615, clamav-milter version 0.73a on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Wed, 13 Oct 2004 12:04:27 +0000 cc: freebsd-current@FreeBSD.org cc: bde@zeta.org.au Subject: Re: panic in ffs (Re: hangs in nbufkv) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 03:43:19 -0000 Matthew Dillon wrote: > Well, it's possible that UFS has bugs related to large block sizes. > People have gotten bitten on and off over the years but usually it > works ok if you leave the 8:1 blocksize:fragsize ratio intact. e.g. > if you have a 64KB block size then you should use a 8K frag size. > If you have a 32KB block size then you should use a 4K frag size. > > This is the case here: fs_bsize 65536, fs_fsize 8192. > I think the buffer cache itself is is likely not the source of this > particular bug. > > I don't know, how, but the bug seems triggered by upping the net.inet.udp.maxdgram from 9216 (default) to 16384 (to match the NFS client's wsize). Once I do that, the machine will either panic or just hang a few minutes into the heavy NFS writing (Sybase database dumps from a Solaris server). Happened twice already... -mi P.S. Thanks for prompt responses and advice, BTW!