From owner-freebsd-fs@FreeBSD.ORG Fri Oct 15 19:32:52 2010 Return-Path: Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 448A3106564A for ; Fri, 15 Oct 2010 19:32:52 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id B0E978FC13 for ; Fri, 15 Oct 2010 19:32:51 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o9FJWYZt066389; Fri, 15 Oct 2010 21:32:50 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o9FJWXb3066388; Fri, 15 Oct 2010 21:32:33 +0200 (CEST) (envelope-from olli) Date: Fri, 15 Oct 2010 21:32:33 +0200 (CEST) Message-Id: <201010151932.o9FJWXb3066388@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, shewless@unleashed-web.org In-Reply-To: X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Fri, 15 Oct 2010 21:32:50 +0200 (CEST) Cc: Subject: Re: consistent file system inconsistencies (tried replacing drive) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, shewless@unleashed-web.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:32:52 -0000 Scott Charron wrote: > I did not create a separate /tmp filesystem so I would guess /tmp is part of > root. I will symlink it to /var/tmp (if it's not already). > > Thanks I'll enable soft-updates and try. It's odd though because > soft-updates are turned off by default on the root FS (when you are > partitioning during install). I think that has only historical reasons. When removing files, soft-updates used to delay the actual freeing of disk space, which was a problem for installworld. It could run out of disk space, even though there was enough space after the old files were freed. This problem was particularly serious for the root file system because it's not very big, typically, and the aborted installworld could render the system unbootable, not even single-user mode. This problem was fixed some time ago, i.e. now the freeing of disk space is not delayed if there is no free space left on the file system. But the default of not enabling soft- updates on the root partition was kept. Normally it's not very important because there aren't many files written to on the root file system during normal operation. Unless you have /tmp or similar things included on your root file system. BTW, you also might want to disable atime-updates on the root-file system (mount option "noatime"), unless you have a reason why you need them. > Also I was under the impression soft-updates would actually require > a little more disk access time and thus make the problem slightly > worse. No, soft-updates doesn't require more disk access time in general. It caches and re-orders meta data updates, so it can even save disk access time. But the important thing is that soft-updates re-orders the meta data updates in a way that guarantees that it is in a consistent state at any time (provided that the disk's firware cooperates correctly). This means that there won't be _unexpected_ inconsistencies after a crash, and fsck will be able to run without user-intervention. (NB: If you want to avoid fsck completely, you will have to use journalling, or go to a ZFS-only system without any UFS file systems.) If you still get unexpected inconsistencies even though you use soft-updates everywhere, then something else must be wrong. Maybe your hard disk doesn't play along nicely. The usual recommendation is to disable the write-cache on hard disks. This will make your system slower, though. > I wouldn't say I have frequent outages, but enough to be very annoying on > this particular system because console/vga access is difficult. I definitely think it's worth buying a UPS. It doesn't have to be a big one. If the outages are very short, it doesn't matter anyway. And if the outages are longer, the UPS just needs to keep the machine running long enough to perform a controlled and clean shutdown. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We will perhaps eventually be writing only small modules which are identi- fied by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." -- Donald E. Knuth, 1974