Slashdot Mirror
Reiser4 Benchmarks
unmadindu writes "Hans Reiser has benchmarked Reiser4 against ext3 and Reiserfs 3. Reiser4 turns out to be way faster than V3, and for ext3, why don't you check out the results yourself ? Hans Reiser states, "these benchmarks mean to me that our performance is now good enough to ship V4 to users", and he will be probably sending in a patch within the next couple of weeks to be included in the 2.6/2.5 kernel."
My one concern is reliability and recovery from failure; I've had a few cases where my belief in ReiserFS has been questioned; however I can't get Ext3 to build on larger than 500GB arrays.
At this point I'd happily choose based on reliability/recoverability/stability not raw speed.
hey, I can live with an unstable gnome or Kicq, but a beta filesystem?? no thanks dude!
I am curious as to whether there are any projects to port Reiser4 to *BSD, particularly FreeBSD 5.x. Does anyone have any thoughts on how difficult a port might be? Can somone more versed in filesystems on *nix enlighten me as to the implimentation differences?
**AA: a bunch of mindless jerks who'll be the first against the wall when the revolution comes
In case anybody cares, "strelka" means "arrow", and "belca" means "squirrel"
Wonder what naming system they're using. I use names from Alice in Wonderland.
After reiser4, what filesystems are actually decent competition for it? It'd be nice for OSS to claim not only the best web server (apache), best kernel, and best filesystem.
--
Sick of gentoo zealots throwing plugs in completely unrelated topics? Me too!
Not to mention the best software installation system ( portage ).
I attended Hans' presentation at Linuxtag.
Basically, reiser4 is optimized for the case where you unpack a large tarball, say the Linux kernel, and have enough memory to hold it all in cache, which is true for most of us these days. reiser4 will then choose the optimal disk layout for these files and flush them to disk.
Hans also has aspects of a log structured file system in reiser4, which means you don't write to the file, you write to a log file which basically encompasses the whole disk. The up side is that you mostly write linearly, the down side is that the files get badly fragmented if they are updated at all. Most files are not updated, just written once at installation of the package. The files that are updated frequently tend to be source code from CVS, which are small enough to fit in memory completely and have reiser4 choose an optimal disk layout again.
The case where this model completely sucks is the case where you update many portions of a large file. For example, running an SQL database with files on a reiser4 file system as backend, or maybe a DNS server with DDNS, or a berkeley db backend for Postfix or qmail to keep the SMTP AUTH users or something. Also, log files will probably be badly fragmented.
Hans proposes to have something like a transparent defragmenter running in the background, which he calls "repacker". This would run in the kernel space, as part of the file system, and defragment badly fragmented files that are accessed frequently. This would solve most of the down sides of his approach, but this repacker is not finished yet.
My personal view of reiser4 is: it looks like it is optimized to perform well in benchmarks. It tries to be fastest for updating databases, but buys the performance by being slower when reading the data afterwards. The critical question is whether the repacker can alleviate these concerns, and as long as it is not finished, reiser4 is basically out of the question except for a little testing here and there. I reckon reiser4 would be a great filesystem for keeping your mozilla and gcc CVS checkout handy. But until the repacker is done, I will not even use it for testing, because the repacker really is the crucial component that makes or breaks this.
By the way: my previous experiences with reiserfs were less than stellar. Some people call it shredderfs instead. The main complaint with reiserfs is and always was that the fsck is not nearly as trustworthy or stable as the one from ext2/ext3. So even if I use reiserfs at all, it's only for data I can afford to lose completely, like my CVS checkouts or the squid cache directories or something like that.
The benchmarks do look good though, and I am glad that at least someone is still trying major innovations in this area. Since most Unix vendors or divisions are no longer profit centers, file system innovations have largely stalled or moved to specialized companies who regard them as proprietary (Veritas) instead of releasing them as free software like IBM and SGI did.
No, V4 is not backward compatible with V3. V3 and V4 are kept as separate codebases so that the new V4 features don't destabilize V3. We are very serious about avoiding adding new features to V3, so that it can become a zero defect product.
However, there is a tool called convertfs (as well as tar) which can convert V3 to V4. It can also convert ext2 to V3 or V4 or V3 or V4 to ext2. It is pretty clever (and written by someone outside our team), in that it creates a loop back mounted target filesystem inside a file inside the source filesystem, copies everything from the source to the target, and then reshuffles the blocks of the file so that they are at the offsets on the device that they were at within the file.
The script that creates the comparison tables divides the other filesystems by the base filesystem. The problem is that Reiser4 was used as the base filesystem in one of the benchmarks, but not the other. So in one benchmark, green is good, and the other benchmark, red is good.
I would have fixed this before posting to lkml, but I had to catch a plane, sorry about that.
That was V3. V4 is an atomic filesystem, which means that every filesystem operation is performed as a fully atomic transaction. This is more secure than the guarantees of data journaling, as data journaling doesn't necessarily guarantee that the write will complete.
The reason we are able to do this in V4 but not in V3 is that V4 uses what I call wandering logs. With wandering logs, instead of copying data first to the journal, and then after commit copying it from the journal to the rest of the filesystem, (thereby writing the data twice), we just change our definition of where the journal is. I don't think that data journaling is worth going half-speed for most users. With V4, we not only don't go half-speed, we go faster than V3 ever went.
For more details, please take a look at http:www.namesys.com/v4/v4.html
XFS is probably one of the fastest journalling filesystems out there, all-round, and probably offers the best competition to Reiser4. I'm actually surprised not to see some benchmarks against it, as XFS has gathered quite a following in places.
The port of the Plan9 filing system is said to be one of the fastest filing systems out there - enough so that it's a part of a Government research program called "Pink", run by some mad scientists at Los Alamos. Yes, that Los Alamos. Again, this would be an excellent FS to have some benchmarks against.
Last, but not least, Reiser4 didn't do spectacularly well against Ext3 in the benchmarks. I saw plenty of results both ways. Reading vs. Deleting, for example, shows a definite penalty whichever FS you choose, depending on the operations you're performing.
In the end, if you truly want the fastest system, you should format partitions according to the type of workload they'll be doing. You want fast deletes on a
(Unless you're using the suspend patch a lot, you probably won't want journalling on the
A truly optimized system, therefore, isn't about picking your "one true love" of the filesystems. It's about deciding what criteria apply, and then looking to see what filesystem best meets that criteria.
A mixed-fs machine should be capable of out-performing ANY homogenous-fs machine, no matter what fs the homogenous-fs machine has picked, because a homogenous system will always be a compromise. A mixed-fs system need compromise nothing. (Other than your sanity. Which, being a geek, is just a hinderence anyway.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
C'mon folks, can't we find someone more authoritative than this guy. I mean, what would someone whose nick is "hansreiser" know about this stuff.