From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 22 18:49:08 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C91E16A40D for ; Mon, 22 Jan 2007 18:49:08 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id EB12713C4CE for ; Mon, 22 Jan 2007 18:49:07 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id l0MIn5VB041817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jan 2007 10:49:07 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id l0MIn56Z041816; Mon, 22 Jan 2007 10:49:05 -0800 (PST) Received: from fbsd61 ([192.168.200.61]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA07030; Mon, 22 Jan 07 10:26:58 PST Date: Mon, 22 Jan 2007 10:29:18 -0800 From: perryh@pluto.rain.com To: vd@freebsd.org Message-Id: <45b5027e.g8Hs/VOZs+63TD6V%perryh@pluto.rain.com> References: <20070119201935.GA60202@x12.dk> <20070120024614.E99400@odysseus.silby.com> <20070122083727.GA61615@qlovarnika.bg.datamax> In-Reply-To: <20070122083727.GA61615@qlovarnika.bg.datamax> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, xride@x12.dk Subject: Re: Where to start? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 18:49:08 -0000 > > I'd like to see the ability to run gjournal without reformatting. > > If you could create a dummy file inside the filesystem, then use > > that area for the journal, it might be possible ... > > I am not sure about gjournal internals but what if a system crash > occurs in the middle of a transaction and the fs gets corrupted > and the data, necessary to fix it is in the journal, but you > cannot access the journal because the file, which contains the > journal, is on a corrupted fs? Looking at this as purely a data-integrity problem, and knowing nothing whatsoever about gjournal internals :) I would guess that if a way could be found to preallocate the journal space (as with mkfile(8) in sufficiently-old systems), and then record its location in a reasonably-secure location (the superblock?), it could be accessed during recovery without reference to possibly-corrupt filesystem metadata.