"Native" journaling file systems?
matthias.andree at gmx.de
Mon Dec 19 13:36:21 PST 2005
Justin Smith <jsmith at drexel.edu> writes:
> Are there any plans to develop UFS3--- i.e., a UFS2 file system with an
> added journal?
> I've used several journaling file systems in Linux and like the Reiser
> FS except for one MAJOR drawback: When something goes wrong, reiser-fsck
> absolutely sucks at repairing things (Hans Reiser freely admits that but
> says it's never needed because nothing ever goes wrong).
I have been using reiserfs for a while, but I ultimately dropped it
again and reverted to ext3fs because I didn't like the sloppy spelling
of the tools to begin with, and the fact that there have always been
accumulated inconsistencies in the on-disk file systems on some systems.
The recent in-kernel versions have been more stable, and reiserfsck has
improved, too, but there are two real showstoppers:
1. the reiserfs team dropped 3.X support and went for reiser4 (I have
been told this is reiser4, not reiserfs4, whatever), leaving 3.X
2. reiserfs 3.6 only supports a limited amount of files with the same
internal hash code per given unit (I don't recall if unit was
directory or file system, probably the former). Some may see this as
pathological, but I see it as a problem.
3. data journalling or data ordering, which Linux ext3fs supported, has
never made official reiserfs 3.X versions as far as I know, which
means NUL blocks showing up in files after crashes. Chris Mason added
such support to SUSE kernels.
So my bottom line is: investing time into reiserfs 3.X is investing time
into a dead product.
I know too little about reiser4, but it has been refused entry to the
baseline Linux kernel several times on technical grounds, and ultimately
the opinions clashed so hard that the reviewer whose opinion was asked
threw in the towel.
My opinion however is that reiser4 is a new product and will not be ripe
before it has been two years in the kernel baseline, and who says that
the guys around Hans Reiser haven't moved on to reiser5 by that time?
After all, ext3fs supports some dirhash variant ("dir_index") which
seems to be pretty unobtrusive, it appears to "just work".
I believe the reason why it was separated (in Linux) from the ext2 code
is to not introduce instabilities or make the code harder to
read. (There's actually another jbd, journalling block device, driver in
Linux, that ext3fs uses.)
More information about the freebsd-current