Journalled UFS

Zhihui Zhang zzhang at
Sat May 15 12:32:00 PDT 2004

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.


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 at mailing list
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at"

More information about the freebsd-fs mailing list