From owner-freebsd-questions@FreeBSD.ORG Tue Apr 7 17:45:18 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 56F60106566B for ; Tue, 7 Apr 2009 17:45:18 +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 30ED58FC0A for ; Tue, 7 Apr 2009 17:45:18 +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 n37HjHQb024790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Apr 2009 10:45:17 -0700 (PDT) (envelope-from bc979@lafn.org) Message-Id: <121ACADA-56B3-4B19-98B4-F0FAF3DFC7E2@lafn.org> From: Doug Hardie To: utisoft@gmail.com, Chris Rees 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: Tue, 7 Apr 2009 10:45:16 -0700 References: <200903311657.n2VGvLE8010101@lurza.secnetix.de> <20090406001614.304360d6@gluon.draftnet> <47952575-35FD-4733-9262-A6DAA3ACB762@lafn.org> 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 Cc: FreeBSD Mailing List 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: Tue, 07 Apr 2009 17:45:18 -0000 On Apr 7, 2009, at 02:34, Chris Rees wrote: > \ > So, the answer is NO, it does NOT cause data CORRUPTION. A simple > reboot solved it? Really, you're advocating guaranteed extended > downtime every time there's a power outage, compared with a slight > chance of a slightly longer downtime while every other time it comes > almost straight up. > > Any more replies, please, read the damned question. You had better define data corruption then. In my book data that is read and gives garbage back rather than the right data is corrupt. It doesn't matter if it gets "fixed" by a reboot later. Thats only helpful if you happen to notice that it needs a reboot. If all you are interested in is toy systems then this type of problem is of no interest to you. However, for those of us who run production systems where clients have paid for service this is a serious issue.