From owner-freebsd-fs@FreeBSD.ORG Wed Mar 10 16:16:14 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 4122516A4CE for ; Wed, 10 Mar 2004 16:16:14 -0800 (PST) Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu [128.213.1.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAFC543D1D for ; Wed, 10 Mar 2004 16:16:13 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from 128.213.50.12 (kiki.cs.rpi.edu [128.213.50.12]) i2B0G9n7094426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Mar 2004 19:16:09 -0500 (EST) From: "David E. Cross" To: Julian Elischer In-Reply-To: References: Content-Type: text/plain Message-Id: <1078964168.4345.27.camel@kiki.cs.rpi.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 10 Mar 2004 19:16:09 -0500 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.37 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: Thu, 11 Mar 2004 00:16:14 -0000 On Wed, 2004-03-10 at 18:55, Julian Elischer wrote: > 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? It has been thought about, and certainly the design would make it trivial at a later point to add. The system does all of the work through vnodes and struct bufs, so they could be backed by "anything" in the future (well, within reason). But for right now its beyond the scope of the project. I am not familiar enough with softupdates and how it functions to even begin to comment on what is or is not possible. We've taken the assumption that they are in no way compatible with each other, and one _or_ the other will be in use, but not both. Once we have some beta-ish code that we can distribute I am sure you can disable the checks (it will just be at mount-time) and see what happens. -- David E. Cross