From owner-freebsd-stable@FreeBSD.ORG Fri Jul 15 22:03:39 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 4388B16A41C for ; Fri, 15 Jul 2005 22:03:39 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1CDE43D46 for ; Fri, 15 Jul 2005 22:03:38 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (p54AA8680.dip0.t-ipconnect.de [84.170.134.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 607B4323E4; Sat, 16 Jul 2005 00:06:30 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j6FM3nsL015084; Sat, 16 Jul 2005 00:03:49 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200507152203.j6FM3nsL015084@drjekyll.mkbuelow.net> From: Matthias Buelow To: Lowell Gilbert In-Reply-To: Message from Lowell Gilbert of "15 Jul 2005 16:15:27 EDT." <44br539674.fsf@be-well.ilk.org> X-Mailer: MH-E 7.84; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Sat, 16 Jul 2005 00:03:49 +0200 Sender: mkb@mkbuelow.net 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 22:03:39 -0000 Lowell Gilbert writes: >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. See my other mail(s) about other systems using cache disabling/enabling to make up for a drive that ignores (or does not implement) a flush command. Then the advice of "disable the wb-cache on disks to ensure data safety" doesn't make sense: Either * the drive supports disabling the write-back-cache, then this method can be used to flush data to the platters, or else * the drive does not support disabling the write-back-cache, or lies about it, then the advice to disable the write-back-cache for softupdates is meaningless. I know my drive allows disabling of the write cache, as, apparently, the majority of IDE/SATA drives do. mkb.