From owner-freebsd-fs@FreeBSD.ORG Fri May 14 10:46: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 54A8416A4CE for ; Fri, 14 May 2004 10:46:14 -0700 (PDT) Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu [128.213.1.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E74A43D55 for ; Fri, 14 May 2004 10:46:13 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from 128.213.50.12 (kiki.cs.rpi.edu [128.213.50.12]) i4EHkBKR045412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2004 13:46:11 -0400 (EDT) From: "David E. Cross" To: freebsd-fs@freebsd.org, wronkm@cs.rpi.edu, moorthy@cs.rpi.edu Content-Type: text/plain Message-Id: <1084556769.2304.20.camel@kiki.cs.rpi.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 14 May 2004 13:46:11 -0400 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.37 Subject: 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: Fri, 14 May 2004 17:46:14 -0000 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