From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 7 19:46:53 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D85E16A420 for ; Tue, 7 Mar 2006 19:46:53 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E33643D45 for ; Tue, 7 Mar 2006 19:46:52 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [127.0.0.1] (localhost.cc.fer.hr [127.0.0.1]) by lara.cc.fer.hr (8.13.4/8.13.4) with ESMTP id k27JkVH0066370 for ; Tue, 7 Mar 2006 20:46:31 +0100 (CET) (envelope-from ivoras@fer.hr) Message-ID: <440DE316.8060604@fer.hr> Date: Tue, 07 Mar 2006 20:46:30 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org References: <25525887.1141742017684.JavaMail.root@vms172.mailsrvcs.net> <20060307162014.GO17589@over-yonder.net> In-Reply-To: <20060307162014.GO17589@over-yonder.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: NetBSD disk backup over network 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: Tue, 07 Mar 2006 19:46:53 -0000 Matthew D. Fuller wrote: >>You can easily save the stream of updates as a redo log (well, >>that's the idea I've been running around with). > > Isn't that what the gjournal SoC thing was about? No, not exactly. The idea was to make a journal of a GEOM device I/O requests on a separate device in the attempt to solve filesystem journaling, but that didn't work out (actually, gjournal works more or less fine, but as far as I understand it, there's a problem similar as with SoftUpdates - even if you journal writes on device level with filesystem mounted "sync", UFS keeps references to inodes in not-entirely-consistent way, so a fsck is always needed after unclean shutdown; in other words, UFS journaling must be done on UFS/VFS level, not GEOM in order to keep track of metadata semantics). Something like a filesystem that doesn't do any read caching, and keeps ALL data ALWAYS in sync with on-disk state could work with gjournal and also with gmirror+geom_gate combination. Such filesystem would probably be similar to GFS, AFAIK.