From owner-freebsd-fs@FreeBSD.ORG Wed Mar 10 15:54:50 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AFE216A4CE for ; Wed, 10 Mar 2004 15:54:50 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC7C443D1F for ; Wed, 10 Mar 2004 15:54:47 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <200403102354460160070kkde>; Wed, 10 Mar 2004 23:54:47 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA81657; Wed, 10 Mar 2004 15:55:55 -0800 (PST) Date: Wed, 10 Mar 2004 15:55:54 -0800 (PST) From: Julian Elischer To: "David E. Cross" In-Reply-To: <1078960907.4345.20.camel@kiki.cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-fs@freebsd.org cc: moorthy@cs.rpi.edu cc: wronkm@cs.rpi.edu Subject: Re: JUFS update, and questions. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2004 23:54:50 -0000 On 10 Mar 2004, David E. Cross wrote: > Journaled UFS Technology Description > [... much good stuff deleted] Not requests for features, just requests as to whether you have considerred these.. Does it have the ability to keep the journal on a separate media? I have sometimes seen the ability to have a separate journal disk used to good effect. (not a system filesystem, but a journalled database). Having a separate journal file/disk elsewhere can speed things up by reducing seeks (and other resiliance advantages). I have also seen double logging and remote logging... each of which of course has advantages and disadvantages.. Remote logging allows the log to be "replayed" at real time in teh remote site, leading to an instantaneously correct remote backup/mirror of the local disk. (of course it can not be safely accessed except with special safety requirements.. (e.g ability to shoot an open vnode if teh inode under it is rewritten) I notice also that you store pre/post stuff and wonder if this can be used in conjunction with soft-update's need to sometimes roll-back things on the disk? julian