From owner-freebsd-stable@FreeBSD.ORG Sat Jul 16 10:17:01 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 753F016A41C for ; Sat, 16 Jul 2005 10:17:01 +0000 (GMT) (envelope-from nicolas@i.0x5.de) Received: from pc5.i.0x5.de (n.0x5.de [217.197.85.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6BD143D46 for ; Sat, 16 Jul 2005 10:17:00 +0000 (GMT) (envelope-from nicolas@i.0x5.de) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id 7FA8581C2A; Sat, 16 Jul 2005 12:16:57 +0200 (CEST) Date: Sat, 16 Jul 2005 12:16:57 +0200 From: Nicolas Rachinsky To: freebsd-stable@freebsd.org Message-ID: <20050716101657.GA44786@pc5.i.0x5.de> 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=us-ascii Content-Disposition: inline In-Reply-To: <200507152342.j6FNg5Tx015427@drjekyll.mkbuelow.net> X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: A32C2932 (Communication) and F66AFAF2 (Certification) X-PGP-Fingerprint1: 97EB FA8B 4C8F A54B D89A 697E A6BC AF72 A32C 2932 (Comm.) X-PGP-Fingerprint2: 1DE8 DF23 56F0 3E14 238D 740C E598 C87E F66A FAF2 (Cert.) X-PGP-Keys: http://www.rachinsky.de/nicolas/pgp/nicolas_rachinsky.asc User-Agent: Mutt/1.5.9i 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 10:17:01 -0000 * Matthias Buelow [2005-07-16 01:42 +0200]: > 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. The track destroyed could contain sectors which are in no way related to the sectors the OS is writing to. Nicolas