Plans for Logged/Journaled UFS

[Jeff Roberson]

On Tue, 22 Dec 2009, Andrew Snow wrote:

>
> Is there any provision to put the journal on a seperate device?  This can 
> solve the performance degradation issue.

Currently there is no plan for it.  The amount of journal data is so small 
compared to typical journaled filesystems I don't think we'll see a 
significant slowdown due to the journal writes.

Consider the operation of creating a new file.  We must write a cyl group 
to allocate a bitmap, an inode block to initialize the new inode, a 
directory block to add the entry, and potentially the directory inode to 
update timestamps, directory size, etc.  So 4 block size writes if there 
is no directory allocation.  The journal adds one 32byte entry to a block 
size write that can commonly hold 512 entries if you can aggregate them.

Another way to look at it is that you can create 512 files (ignoring 
directory block allocation) before you need to write the journal.

With full metadata block journaling you're writing the full size of each 
of those 4 blocks every time a change is made.  On a 16k block filesystem 
that's 64k vs our 32 bytes.

We can accomplish this because the recovery operation is smart enough to 
parse all the metadata and see how far along the operation is. 
Softupdates orders writes well enough that we only have to handle a small 
number of failure cases and can make big assumptions about the state of 
the filesystem.  If any of these assumptions are not true we still have a 
full fsck to fall back on.

Thanks,
Jeff

>
>
> - Andrew
> _______________________________________________
> 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"
>