From owner-freebsd-stable@FreeBSD.ORG Tue Sep 12 11:57:12 2006 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 A410F16A415 for ; Tue, 12 Sep 2006 11:57:12 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from ferengi.borderworlds.dk (ferengi.borderworlds.dk [80.166.152.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 202FA43D73 for ; Tue, 12 Sep 2006 11:57:12 +0000 (GMT) (envelope-from xi@borderworlds.dk) Received: from dominion.borderworlds.dk (dominion.borderworlds.dk [10.1.0.10]) by ferengi.borderworlds.dk (Postfix) with ESMTP id 4990EB913 for ; Tue, 12 Sep 2006 13:57:11 +0200 (CEST) Received: by dominion.borderworlds.dk (Postfix, from userid 2000) id 674748C8; Tue, 12 Sep 2006 13:57:10 +0200 (CEST) To: freebsd-stable@freebsd.org References: <45066E19.2040405@kuehlbox.de> From: Christian Laursen Date: Tue, 12 Sep 2006 13:57:10 +0200 In-Reply-To: (Ivan Voras's message of "Tue, 12 Sep 2006 13:38:49 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: gjournal and Softupdates 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: Tue, 12 Sep 2006 11:57:12 -0000 Ivan Voras writes: > Christian Laursen wrote: > >> Journaling also needs writes to be done in the correct order. You don't >> want to write the real update to the filesystem before you have made sure > > Ok, but journal is (or should be) protected by checksumming or some > kind of record markers, so invalid entries are not replayed. That is not the issue. Recognizing valid journal entries should be easy enough. Consider the following sequence of events: 1. Data A is written to the journal 2. The journal is flushed to disk 3. Data A is written to the filesystem Now consider what happens if the disk is reordering writes: 1. Data A is partially written to the journal 2. Data A is partially written to the filesystem 3. The system crashes You now have an invalid journal entry for data A which will not be replayed and some unkown amount of the data is already written to the filesysten possibly leaving it in an inconsistent state. -- Christian Laursen