From owner-freebsd-questions@FreeBSD.ORG Tue Dec 8 11:07:52 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D66F106566B for ; Tue, 8 Dec 2009 11:07:52 +0000 (UTC) (envelope-from cronfy@sprinthost.ru) Received: from odin.from.sh (odin.from.sh [80.93.50.112]) by mx1.freebsd.org (Postfix) with ESMTP id 085EF8FC1D for ; Tue, 8 Dec 2009 11:07:51 +0000 (UTC) Received: from odin.from.sh ([80.93.50.112]) by odin.from.sh with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NHxuZ-0008Pn-OZ for freebsd-questions@freebsd.org; Tue, 08 Dec 2009 14:07:19 +0300 Received: from [194.8.176.106] (helo=[192.168.0.3]) by odin.from.sh with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NHxuT-0008PG-Mq for freebsd-questions@freebsd.org; Tue, 08 Dec 2009 14:07:13 +0300 Message-ID: <4B1E33CF.1070309@sprinthost.ru> Date: Tue, 08 Dec 2009 14:09:03 +0300 From: cronfy User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <4B1DF953.4050504@sprinthost.ru> <4B1E2D40.9060900@sprinthost.ru> <20091208114509.B67127@gwdu60.gwdg.de> In-Reply-To: <20091208114509.B67127@gwdu60.gwdg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD is too filesystem errors sensitive X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 11:07:52 -0000 >>>> panics like 'freeing free block' or 'ffs_valloc: dup alloc' >> >> Is there a way to say "Dear kernel, don't panic, I'am holding your >> hand, keep working please-please-please?" If so, can it lead to >> complete filesystem corruption indeed or it is not so serious? > > Afaik you can't do this. And you shouldn't do if it'd be possible. The > file system errors you mention above should not happen under any > normal circumstances. They may happen after a crash caused by other > reasons but should get repaired by fsck. The kernel cannot continue > with such errors because the whole file system metadata cannot be > trusted anymore until repaired. > Thanks. What I can definitely state is that after reboot nothing will get any better. I will have same filesystem with same errors + new errors that appeared because soft-updates were not synced, and I will have fsck running in background. I'd prefer to just start fsck in background, skipping that annoying reboot phase ;-) Am I willing strange?