From owner-freebsd-fs@FreeBSD.ORG Sat May 15 12:32:00 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 4479816A4CE for ; Sat, 15 May 2004 12:32:00 -0700 (PDT) Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D61943D46 for ; Sat, 15 May 2004 12:31:59 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from opal (cs.binghamton.edu [128.226.123.101]) i4FJVip8009514; Sat, 15 May 2004 15:31:44 -0400 (EDT) Date: Sat, 15 May 2004 15:31:44 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@opal To: "David E. Cross" In-Reply-To: <1084556769.2304.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: Journalled UFS 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: Sat, 15 May 2004 19:32:00 -0000 I did a journaling file system called yFS and I have two suggestions: (1) Do piecemeal logging - only log the portion of metadata that has been changed. SGI's XFS does this. (2) There is no need to lock inode within a journaling file system. The VFS layer already does this. Be careful with free inode reclamation. You may want to read our FAST'03 paper on yFS. Good luck with your work. -Zhihui On 14 May 2004, David E. Cross wrote: > Ok... It was brought to my attention that someone was asking for this > again, so I figure its time to put out an update on the status. > > The journalling is done. There are a couple of fixes that need to be > applied (rename currently panics), and we are logging too much data for > inode updates (we currently log all data for any inode update). > Additionally we need to move the mutex locks up to the VFS/VOP interface > layer (question regarding this will follow). > > After this its just fsck changes, and we have a register based machine > state to parse from (opcodes and operands) so it should be downright > trivial with the exception of metadata blocks that decame data blocks. > I have a couple of ideas to work around those issues as well). > > Performance? Well, its better than softupdates. But some of the > changes we make _may_ change that. We'll see. Also the devel machine > isn't that hefty (either RAM or CPU). Also this loses the ability for > snapshots. > > We have a paper deadline for this in about ~1 month, and I'd like to get > the rest of this finished up. > > Ok.. now for the mutex questions. What we are looking to do is have the > mutexes be dual use. 1) for MP/MT-safeness. 2) for > re-entrancy/FS-stacking. > > Here's what I want to do: > > VOP/VFS entry point { > Aquire Mutex with RECURSION; > If first aquire, inc transaction ID; else don't; > > NORMAL VOP/VFS Dispatch; > > Release Mutex; > if last release && syn_journal Checkpoint_Routine; > } > > Checkpoint_Routine { > Aquire mutex with RECURSION: > if first aquire, last_tid=TID; > else last_tid=TID-1; > > Dump_to last_tid; > > Release mutex; > } > > I am not sure how to check if we already have a mutex, and if its > recursion or not vs. the mutex is already aquired but its not "ours". > suggestions? > > Recursion is important for stackable FSs, things like quotas, vnode > backed "devices", etc. > > Suggestions? > > -- > David E. Cross > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >