From owner-freebsd-questions@FreeBSD.ORG Tue Dec 8 12:32:16 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 A87421065693 for ; Tue, 8 Dec 2009 12:32:16 +0000 (UTC) (envelope-from kheuer2@gwdg.de) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by mx1.freebsd.org (Postfix) with ESMTP id 391CA8FC0A for ; Tue, 8 Dec 2009 12:32:16 +0000 (UTC) Received: from gwdu60.gwdg.de ([134.76.8.60]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NHzEg-0001FG-9k; Tue, 08 Dec 2009 13:32:10 +0100 Date: Tue, 8 Dec 2009 13:32:09 +0100 (CET) From: Konrad Heuer To: cronfy In-Reply-To: <20091208113023.GA1828@owl.midgard.homeip.net> Message-ID: <20091208132720.G67127@gwdu60.gwdg.de> References: <4B1DF953.4050504@sprinthost.ru> <4B1E2D40.9060900@sprinthost.ru> <20091208114509.B67127@gwdu60.gwdg.de> <4B1E33CF.1070309@sprinthost.ru> <20091208113023.GA1828@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-questions@freebsd.org 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 12:32:16 -0000 On Tue, 8 Dec 2009, Erik Trulsson wrote: > On Tue, Dec 08, 2009 at 02:09:03PM +0300, cronfy wrote: >> >>>>>> 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? > > Background fsck can only handle a few, very specific, filsystem problems. > (Basically situations where blocks are marked as being in use, even though > they are not really used by anything. Softupdates is supposed to guarantee > that those are the only types of filesystem errors that can occur, but in > reality that guarantee does not always hold.) > > If you have other instances of filesystem corruption (which includes > everything which can trigger a kernel panic) you need to use a foreground > fsck to fix it. That's true. You should go down to single user mode by entering "shutdown now", unmount your filesystems ("umount -a -t ufs") and check your filesystem by "fsck -y". Please read "man fsck" before since implicitly answering all questions with yes by "-y" may cause loss of data !!! (To tell the truth: You probably have to do so anyway.) > Personally I would recommend not using background fsck at all unless you > know exactly what you are doing and why. Best regards Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, kheuer2@gwdg.de