From owner-freebsd-questions@FreeBSD.ORG Mon Apr 6 20:46:48 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 E16B31065795 for ; Mon, 6 Apr 2009 20:46:48 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [206.117.18.8]) by mx1.freebsd.org (Postfix) with ESMTP id 93C3B8FC08 for ; Mon, 6 Apr 2009 20:46:48 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.2] (pool-71-109-162-173.lsanca.dsl-w.verizon.net [71.109.162.173]) (authenticated bits=0) by zoom.lafn.org (8.14.2/8.14.2) with ESMTP id n36KklWI088243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 6 Apr 2009 13:46:47 -0700 (PDT) (envelope-from bc979@lafn.org) Message-Id: <47952575-35FD-4733-9262-A6DAA3ACB762@lafn.org> From: Doug Hardie To: FreeBSD Mailing List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 13:46:46 -0700 References: <200903311657.n2VGvLE8010101@lurza.secnetix.de> <20090406001614.304360d6@gluon.draftnet> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on zoom.lafn.org X-Virus-Status: Clean Subject: Re: Question about forcing fsck at boottime 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: Mon, 06 Apr 2009 20:46:51 -0000 On Apr 6, 2009, at 11:12, Chris Rees wrote: > Can > no-one can come up with a reply either quoting a mailing list or > giving the circumstances when: > > a) Background fsck caused data CORRUPTION > > _and_ > > b) A foreground fsck would not have done the same > > ? Yes. When background FSCK first became standard I let it go that way on my production servers. The first time we had a power issue that resulted in a shutdown of a server it tried to come back up when the power was restored. I have a large number of daemons that rely on configure files and other information that is reasonably frequently updated. Some of those files were in the process of being updated when it shut down. As a result background FSCK did not get around to those files till much after the daemons were up and running (or trying to run). Most of them worked ok at the beginning. However after FSCK resolved the problems, the underlying files changed. The daemons couldn't function at that point. While a simple reboot at that point fixed everything, that caused yet another outage for users. Hence, I disabled background FSCK. There have been a few power issues since then and there have been no recovery issues with foreground FSCK other than the restart takes a bit longer. This is reproducible since it happened on several different servers. However, I am not about to go back and subject users to additional downtime when a viable workaround that avoids the problem exists. I doubt that the concept of background FSCK is broken and I suspect that the implementation is good too. The issue is that some services really should not be started till after FSCK (either variety) has completed. I didn't see an easy way to do that using rc.