From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 03:43:20 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 5C2F516A4CE for ; Wed, 13 Oct 2004 03:43:20 +0000 (GMT) Received: from corbulon.video-collage.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2C2043D1D for ; Wed, 13 Oct 2004 03:43:19 +0000 (GMT) (envelope-from Mikhail.Teterin@murex.com) Received: from 250-217.customer.cloud9.net (195-11.customer.cloud9.net [168.100.195.11])i9D3etnq057896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Oct 2004 23:43:18 -0400 (EDT) (envelope-from Mikhail.Teterin@murex.com) Received: from [127.0.0.1] (mteterin@localhost [127.0.0.1]) i9CHvalr031794; Tue, 12 Oct 2004 13:57:36 -0400 (EDT) (envelope-from Mikhail.Teterin@murex.com) Message-ID: <416C1B10.7030103@murex.com> Date: Tue, 12 Oct 2004 13:57:36 -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> In-Reply-To: <200410112038.i9BKcCWt051290@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: 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:20 -0000 Matthew Dillon wrote: >:One of our file systems here does, indeed, use large block size (64K, I >:think, not sure, how to verify it) -- it is used for storing large >:database dumps. Are the bugs, Bruce and Matt are talking about, supposed >:to be gone by now (in which case, I can provide more debugging info), or >:does this remain a "known problem" and I should simply adopt the >:workaround suggested by Bruce in the first link above -- increase >:BKVASIZE? Should I also merge the patch posted by Bruce in the last of >:the links above, or are there good reasons, it is not in the official tree? > > [...] > But to be absolutely safe, I would follow Bruce's original suggestion > and increase BKVASIZE to 64K, for your particular system. > > After doing this and testing our backup script, the machine panicked two hours later (about half-way through the backup) with "initiate_write_inodeblock_ufs2: already started" (in ufs/ffs/ffs_softdep.c)... I guess, block sizes above 16Kb are just buggy and newfs(8) should be honest about it... -mi