From owner-freebsd-stable@FreeBSD.ORG Sat Jul 16 13:35:42 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 5C07516A41C for ; Sat, 16 Jul 2005 13:35:42 +0000 (GMT) (envelope-from davidt@yadt.co.uk) Received: from outcold.yadt.co.uk (outcold.yadt.co.uk [81.187.204.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D97243D45 for ; Sat, 16 Jul 2005 13:35:40 +0000 (GMT) (envelope-from davidt@yadt.co.uk) Received: from localhost (localhost [127.0.0.1]) by outcold.yadt.co.uk (Postfix) with ESMTP id E72151DD546 for ; Sat, 16 Jul 2005 14:37:20 +0100 (BST) Received: from outcold.yadt.co.uk ([127.0.0.1]) by localhost (outcold.yadt.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62929-06 for ; Sat, 16 Jul 2005 14:37:10 +0100 (BST) Received: by outcold.yadt.co.uk (Postfix, from userid 1001) id 519311DD6B0; Sat, 16 Jul 2005 14:37:10 +0100 (BST) Date: Sat, 16 Jul 2005 14:37:10 +0100 From: David Taylor To: freebsd-stable@freebsd.org Message-ID: <20050716133710.GA71580@outcold.yadt.co.uk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20050715224650.GA48516@outcold.yadt.co.uk> <200507152342.j6FNg5Tx015427@drjekyll.mkbuelow.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <200507152342.j6FNg5Tx015427@drjekyll.mkbuelow.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: amavisd-new 2.3.1 (20050509) at yadt.co.uk 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 13:35:42 -0000 On Sat, 16 Jul 2005, Matthias Buelow wrote: > David Taylor writes: > > >> A corrupted journal can be detected. If it's corrupted, discard > >> the whole thing, or only the relevant entry. The filesystem will > >> remain consistent. > >> If track corruption occurs after the journal is written, it doesn't > >> matter, since at boot the journal will be replayed and all operations > >> will be performed once more. > > > >The track which is corrupted could contain data that wasn't written > >to in months. How would the journal help? > > I don't understand this question. When the drive is powered off, the track being written to at that point may be corrupted, right? That track may contain sectors that the OS did't change. These sectors would not be mentioned in the journal. How would a journaling fs fix the corruption? I suppose this could be avoided by requiring that all writes (and journal entries) somehow correspond to a full track. (Which I suppose they may do already, but I don't think so). > >I still don't trust ATA drives. Can you guarantee (or show any > >reason to believe) that disabling the write cache will actually > >wait for the cache to be flushed before returning? > >Otherwise a sequence is exactly > >the same as a command. If the drive executes > >both immediately, without waiting for the cache to be > >flushed _before_ returning, what's the difference? > > You imply that, because there exists one drive for which it doesn't > work, that it follows that it won't work for all drives? Or what is your > point? No. I'm just asking if you know of ANY ata drives that will wait for the cache to be flushed before claiming the disable cache command has succeeded. I don't, but I haven't looked. -- David Taylor