Journalled UFS

David E. Cross crossd at
Fri May 14 10:46:14 PDT 2004

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

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

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".

Recursion is important for stackable FSs, things like quotas, vnode
backed "devices", etc.


David E. Cross

More information about the freebsd-fs mailing list