From owner-freebsd-stable@FreeBSD.ORG Sat Jul 16 17:04:20 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 4BDB516A41C for ; Sat, 16 Jul 2005 17:04:20 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id E89EF43D45 for ; Sat, 16 Jul 2005 17:04:19 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: (qmail 14284 invoked from network); 16 Jul 2005 17:04:19 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Jul 2005 17:04:19 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id ED92027; Sat, 16 Jul 2005 13:04:17 -0400 (EDT) Sender: lowell@be-well.ilk.org To: Paul Mather References: <20050715224650.GA48516@outcold.yadt.co.uk> <200507152342.j6FNg5Tx015427@drjekyll.mkbuelow.net> <20050716133710.GA71580@outcold.yadt.co.uk> <20050716141630.GB752@drjekyll.mkbuelow.net> <1121530912.17757.32.camel@zappa.Chelsea-Ct.Org> From: Lowell Gilbert Date: 16 Jul 2005 13:04:17 -0400 In-Reply-To: <1121530912.17757.32.camel@zappa.Chelsea-Ct.Org> Message-ID: <44k6jqof72.fsf@be-well.ilk.org> Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org, Matthias Buelow 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: Sat, 16 Jul 2005 17:04:20 -0000 Paul Mather writes: > Despite that, I have never EVER had a problem with data consistency on > my file systems. (The only problem I have had is when I added an ATA > controller card one time and forgot to disable its RAID BIOS, which > promptly spammed over my geom_mirror metadata.:) If softupdates were as > unsafe as you often hint, I'm surprised that I haven't lost a file > system by now. (I would also expect to hear from the field a lot more > clamour about how unsafe it is, and that, in fact, the sky was indeed > falling.) I guess I must be amazingly lucky and should start playing > the lottery right now. :-) Well, break it down a little bit. If an ATA drive properly implements the cache flush command, then none of the ongoing discussion is relevant. Herr Buelow is worried about drives that do *not* do so, but which, when told to disable their cache, will reliably empty the cache before continuing with further operations. Such drives are the only ones to which any of the discussion applies. If such drives are reasonably common, then using such a hack would make sense. However, I would want some fairly solid evidence on the matter before I was willing to start coding it, and so far the most convincing evidence I have seen is that Microsoft engineers claim to have done it. Be well.