Journalled UFS

[Zhihui Zhang]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>