Weblog entry #3 for glanz
See all weblog entries made by glanz.
#3
ReiserFS vs. ext3
Posted by glanz on Sun 4 Feb 2007 at 12:04
This interview is revealing. Now I don't know how true or false the statements Hans Reiser makes here, but if they are more or less true, then that's not promising: http://kerneltrap.org/node/5654
quote:
Jeremy Andrews: How much effort does Namesys have to put into the support of Reiser3?
Hans Reiser: We didn't start V4 until V3 was stable. After we started V4 we hired one guy to do most of the V3 bug fixes, which were mostly in the newer journaling code, and then after a year the bug reports mostly stopped coming in. The bugs that do get reported now are always in the new features added by the SuSE guys. I am a big believer in the let there be a stable branch of the code with no new features model of software development. This makes me a bit of a heretic in the lkml community, but oh well.
From "slh" @ Sidux
quote:
While technically correct, this perception doesn't represent the actual state of affairs. True is that Namesys put reiserfs 3.6 into a strict feature freeze/ deep maintenance mode in favour of the upcoming (still not ready for prime time and not backwards compatible) reiser4 a few years ago - at that stage it dealt better with lots of small files than concurrent filesystem at that time, at least regarding speed that statement isn't true anymore with other filesystems improving and reiserfs stagnating. SuSE delayed that stagnation to actually meet the needs of contemporary use cases with its own developers (until the end of 2006 up to 3 developers almost exclusively for reiserfs 3.6 development), ACLs, xattrs, proper quota support, online resizing are still missing from reiserfs 3.6 completely. These changes (basically leading to a compatible reiserfs 3.6.1 or something like that) introduced regressions like any other developments and SuSE tried to fix them as they got noticed.
Right now with harddisks getting larger, xattrs and quotas becoming more important, clustering becoming a serious need, the old reiserfs 3.6 code isn't easy to keep on par any longer while concurrent file systems handle these issues easily while keeping up-/ and backwards compatibility, performance and journalling stability isn't an advantage for reiserfs any more because other filesystems were able to catch up and even overtake reiserfs 3.6 in the mean time (reiser4 is a complete new and incompatible filesystem, not a natural successor that could be upgraded - fragmentation and stability issues are also quite nasty). For these reasons Novell/ SuSE decided to follow Namesys' lead and cease all efforts regarding future development of reiserfs 3.6 and to switch to ext3/ ext4 while promising to provide further (deep) maintenance, as they're required to do for their existing (enterprise) user base anyways.
In my opinion it is sad that all further development of reiserfs 3.6 has been halted, because the b-tree approach and leaf packing had undeniable advantages for performance and overhead regarding lots of small files - but it also limited further development of the on-disk format as well. What is to be expected for reiserfs 3.6 in the future, SuSE will most likely look after serious bugs in reiserfs for the foreseable future, but personally I won't trust my data to a file system without active (!= deep) maintenance and that neglection is already showing in some rather serious bugs in reiserfs still present kernel 2.6.19 and 2.6.20, besides that alternative filesystems are also getting better than the current state of affairs for reiserfs 3.6 regarding stability and performance because those are still actively developed and not static targets without any improvements. This means that I don't consider reiserfs 3.6 a decent choice for "newly created" filesystems, but transitioning existing filesystems might not be a prime priority either - reiserfs is still there and won't go away in the next 5+ years<fullstop>.
If you want to transition away from reiserfs, "cp -a", "rsync -a", "tar -cjf" and subsequent "mkfs -t <insert_your_filesystem_of_choice_here>" (rather easy with external USB/ firewire/ eS-ATA disks or free space on different partitions) are the weapons of choice.
Post scriptum:
- please read http://lists.opensuse.org/opensuse-factory/2006-09/msg00542.html and subsequent clarifications regarding SuSE's point of view.
- reiser4 is a completely different filesystem and incompatible to reiserfs 3.6; up- or downgrades are not possible at all, therefore its development is as unrelated to these issues/ discussions as ext4, xfs, jfx, ufs2, zfs, ntfs/ hpfs, vfat would be.
- I'd recommend ext3 for new general purpose filesystems.
quote:
Jeremy Andrews: How much effort does Namesys have to put into the support of Reiser3?
Hans Reiser: We didn't start V4 until V3 was stable. After we started V4 we hired one guy to do most of the V3 bug fixes, which were mostly in the newer journaling code, and then after a year the bug reports mostly stopped coming in. The bugs that do get reported now are always in the new features added by the SuSE guys. I am a big believer in the let there be a stable branch of the code with no new features model of software development. This makes me a bit of a heretic in the lkml community, but oh well.
From "slh" @ Sidux
quote:
While technically correct, this perception doesn't represent the actual state of affairs. True is that Namesys put reiserfs 3.6 into a strict feature freeze/ deep maintenance mode in favour of the upcoming (still not ready for prime time and not backwards compatible) reiser4 a few years ago - at that stage it dealt better with lots of small files than concurrent filesystem at that time, at least regarding speed that statement isn't true anymore with other filesystems improving and reiserfs stagnating. SuSE delayed that stagnation to actually meet the needs of contemporary use cases with its own developers (until the end of 2006 up to 3 developers almost exclusively for reiserfs 3.6 development), ACLs, xattrs, proper quota support, online resizing are still missing from reiserfs 3.6 completely. These changes (basically leading to a compatible reiserfs 3.6.1 or something like that) introduced regressions like any other developments and SuSE tried to fix them as they got noticed.
Right now with harddisks getting larger, xattrs and quotas becoming more important, clustering becoming a serious need, the old reiserfs 3.6 code isn't easy to keep on par any longer while concurrent file systems handle these issues easily while keeping up-/ and backwards compatibility, performance and journalling stability isn't an advantage for reiserfs any more because other filesystems were able to catch up and even overtake reiserfs 3.6 in the mean time (reiser4 is a complete new and incompatible filesystem, not a natural successor that could be upgraded - fragmentation and stability issues are also quite nasty). For these reasons Novell/ SuSE decided to follow Namesys' lead and cease all efforts regarding future development of reiserfs 3.6 and to switch to ext3/ ext4 while promising to provide further (deep) maintenance, as they're required to do for their existing (enterprise) user base anyways.
In my opinion it is sad that all further development of reiserfs 3.6 has been halted, because the b-tree approach and leaf packing had undeniable advantages for performance and overhead regarding lots of small files - but it also limited further development of the on-disk format as well. What is to be expected for reiserfs 3.6 in the future, SuSE will most likely look after serious bugs in reiserfs for the foreseable future, but personally I won't trust my data to a file system without active (!= deep) maintenance and that neglection is already showing in some rather serious bugs in reiserfs still present kernel 2.6.19 and 2.6.20, besides that alternative filesystems are also getting better than the current state of affairs for reiserfs 3.6 regarding stability and performance because those are still actively developed and not static targets without any improvements. This means that I don't consider reiserfs 3.6 a decent choice for "newly created" filesystems, but transitioning existing filesystems might not be a prime priority either - reiserfs is still there and won't go away in the next 5+ years<fullstop>.
If you want to transition away from reiserfs, "cp -a", "rsync -a", "tar -cjf" and subsequent "mkfs -t <insert_your_filesystem_of_choice_here>" (rather easy with external USB/ firewire/ eS-ATA disks or free space on different partitions) are the weapons of choice.
Post scriptum:
- please read http://lists.opensuse.org/opensuse-factory/2006-09/msg00542.html and subsequent clarifications regarding SuSE's point of view.
- reiser4 is a completely different filesystem and incompatible to reiserfs 3.6; up- or downgrades are not possible at all, therefore its development is as unrelated to these issues/ discussions as ext4, xfs, jfx, ufs2, zfs, ntfs/ hpfs, vfat would be.
- I'd recommend ext3 for new general purpose filesystems.