Plans for Logged/Journaled UFS
Jeff Roberson
jroberson at jroberson.net
Tue Dec 22 23:34:44 UTC 2009
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"
>
More information about the freebsd-fs
mailing list