From owner-freebsd-stable@FreeBSD.ORG Tue Jan 4 12:21:00 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F3AA16A4CE for ; Tue, 4 Jan 2005 12:21:00 +0000 (GMT) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D754B43D3F for ; Tue, 4 Jan 2005 12:20:59 +0000 (GMT) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from localhost (localhost [127.0.0.1])B56514D1B4 for ; Tue, 4 Jan 2005 13:20:58 +0100 (CET) Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30109-03 for ; Tue, 4 Jan 2005 13:20:58 +0100 (CET) Received: from m2a2.dyndns.org (pD9FFB7F2.dip.t-dialin.net [217.255.183.242]) D032949C46 for ; Tue, 4 Jan 2005 13:20:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 8E3BD77648 for ; Tue, 4 Jan 2005 13:20:58 +0100 (CET) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10053-07-4 for ; Tue, 4 Jan 2005 13:20:57 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id D686377651; Tue, 4 Jan 2005 13:20:57 +0100 (CET) From: Matthias Andree To: freebsd-stable@freebsd.org In-Reply-To: <41DA6E6C.8030505@yahoo.com> (spamrefuse@yahoo.com's message of "Tue, 04 Jan 2005 19:22:36 +0900") References: <41DA6E6C.8030505@yahoo.com> Date: Tue, 04 Jan 2005 13:20:57 +0100 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at dt.e-technik.uni-dortmund.de Subject: Re: fsck: broken file system with background check remains broken after bootup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 12:21:00 -0000 Rob writes: > I had following situation: > > Someone suddenly cut the power of a FreeBSD 5.3 PC, leaving the /usr > filesystem in a very broken state. During next bootup, there was indeed > the message telling 'not properly unmounted', but boot continued with > background fsck after 60 seconds; although I have > fsck_y_enable="YES" > in /etc/rc.conf. That is the one that may cause problems. The default fsck settings are conservative so as to only make "safe" changes. fsck -y also makes more radical changes to your file system. OTOH, I am not convinced that fsck (particularly bgfsck) is bug-free, I have seen file system corruption on a FreeBSD 4.10 system that went with the write caches disabled. > This scared me. What if /usr was such broken that even single user mode > would hang!?! Don't worry as long as /usr is separate from /. > Moreover, the main user of this PC is not a Unix guru and I hoped that > the configuration setting in /etc/rc.conf of fsck_y_enable would do an > automatic fix at bootup, like it used to do with 4.10. However, that > apparently does not happen anymore. > > What can I do to enforce an immediate fix of the filesystems at bootup > with FreeBSD 5.3, when a filesystem is not properly unmounted at shutdown? > > I suppose I should not change default background_fsck ("YES"). How about > the background_fsck_delay? Should I set this to "0"? Setting background_fsck=NO should be safe and cause the fsck to run in foreground - exactly your desire. I would avoid touching the background_fsck_delay. If, as you say, the main user of the PC is not a guru and shuts down the machine improperly, consider disabling the write cache. For ATA drives, place hw.ata.wc="0" into /etc/loader.conf.local and reboot, for SCSI drives, use "camcontrol modepage da0 -m8 -e -P3" and change the figure on the WCE: line to 0, then save and exit; repeat for all further da* drives if you have more than one. That will limit the potential damage on the disk to one block rather than the whole of the cache, which is between 2 and 8 MB on the common drives sold today. -- Matthias Andree