Date: 10 Mar 2004 19:16:09 -0500 From: "David E. Cross" <crossd@cs.rpi.edu> To: Julian Elischer <julian@elischer.org> Cc: wronkm@cs.rpi.edu Subject: Re: JUFS update, and questions. Message-ID: <1078964168.4345.27.camel@kiki.cs.rpi.edu> In-Reply-To: <Pine.BSF.4.21.0403101546090.15852-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0403101546090.15852-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1078964168.4345.27.camel>