From owner-freebsd-stable@FreeBSD.ORG Fri Jul 15 20:15:28 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org 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 E92E116A41C for ; Fri, 15 Jul 2005 20:15:28 +0000 (GMT) (envelope-from lowell@be-well.ilk.org) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BBBA43D48 for ; Fri, 15 Jul 2005 20:15:28 +0000 (GMT) (envelope-from lowell@be-well.ilk.org) Received: (qmail 17769 invoked from network); 15 Jul 2005 20:15:28 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail25.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Jul 2005 20:15:28 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 5533938; Fri, 15 Jul 2005 16:15:27 -0400 (EDT) Sender: lowell@be-well.ilk.org To: Matthias Buelow References: <42D6B117.5080302@plab.ku.dk> <20050714191449.A8A615D07@ptavv.es.net> <20050714195253.GA23666@drjekyll.mkbuelow.net> <20050715185413.GI37261@funkthat.com> <20050715192928.GB1374@drjekyll.mkbuelow.net> From: Lowell Gilbert Date: 15 Jul 2005 16:15:27 -0400 Message-ID: <44br539674.fsf@be-well.ilk.org> Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: John-Mark Gurney , freebsd-stable@freebsd.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2005 20:15:29 -0000 Matthias Buelow writes: > The combination barriers+journal really seems to be very resilient > to filesystem corruption. When it's implemented without errors, and > the hardware doesn't do things like change bits randomly, I can't > think of a way this scheme can be corrupted at all. We keep trying to point out that barriers *can't* be enforced on the hardware with many (most, and apparently an increasing percentage of) ATA drives. There is no semantic on these drives that allows you to guarantee the journal block will be written before the corresponding data block. If you are sure that your drives do this properly, then you are safe, but in that case there's no reliability problem with softupdates, either.