Welcome to the Reiser4 Wiki, the Wiki for users and developers of the ReiserFS and Reiser4 filesystems.
For now, most of the documentation is just a snapshot of the old Namesys site (archive.org, 2007-09-29).
There was also a Reiser4 Wiki (archive.org, 2007-07-06) once on pub.namesys.com.
from Philipp Guehring
ReiserFS is the main engine behind our LivingXML database system. After we found that other XML databases simply can not provide the needed scalability, we started to develop a native XML engine based on ReiserFS. With the great help of ReiserFS, we now have one of the best database systems, which is scalable, flexible, and just does what our customers need.
Filesystems are the best databases we have, but only a few people seem to care or use them appropriatly. We have created a database application with ~ 250 000 XML files, and searches, updates, ... are performing very well. Just visit http://www.livingxml.net/ to see the combination of XML and ReiserFS.
FTP server of Source Forge has 850GB storage, half of which is reiserfs, half is ext2. Both filesystems have been running flawlessly for > 4 months of production (actually longer, but wasn't reiserfs before). That server pushes between 15Mbit and 50Mbit/sec, and pulls/syncs about 2-5Mbit/sec, 24x7.
reiserfs also powers the CVS tree filesystem for cvs-mirror.mozilla.org (also tokyojoe.sourceforge.net), which is the one and only anonymous CVS checkout point for mozilla. That server has run flawlessly under very heavy load since its birth.
I don't get involved in kernel politics, but as a production filesystem, reiserfs is ok in my book.
from another happy user
ReiserFS is running on our production squid server (20G spool), and production news server (currently 40G, will be 500G soon), serving about 500 DSL customers. Never had a problem, upgraded from 3.5 to 3.6 without a hitch.
from Kenneth C. Arnold
Wow -- what a filesystem. You know which one I'm talking about ;) Just had a major freeze (v. rare with Linux, but it happens) where I had to use the one-finger kick. I had converted /usr to ReiserFS, but hadn't gotten to /var yet. Well needless to say /usr survived, and /var... ever tried having duplicate blocks between (in my case) (/var)/lib/dpkg/info/libc6-prerm (a file) and (/var)/ (quite definately a directory)? I have always thought of Linux filesystems as being very delicate in comparison to the filesystem for That Other OS ... until now.
from Bryan Campbell
As expected . . . the patch was quite successful. I am totally amazed at reiserfs
422GB of news on the spool at 1:01 a.m. (expire started)
320GB of news on the spool at 1:03 a.m. (expire finished)
I have to admit that I am not privy to a lot of high performance file systems of proprietary nature. But, I know of no file system that can release that kind of space on an innd installation in under 3 minutes. Mind you that is the entire expiration time. The current history file is 146MB. That three minutes includes parsing the history file. Even when it was broken, it would expire 250GB of news in under 7 minutes. With ext2 it took roughly twice the time.
I also have a cache server (squid 2.4.blah) running over 4X10GB cache-dirs. It sustains loads of between 300-600 concurrent connections. ext2 just fell over at about 425 connections. I have yet to reach the limit of reiserfs on the cache server. And, I still have yet to install the current patch. I am guessing that I will try reiser raw with squid before too long.
I know this is not supposed to be a testimonial, but, how's this . . . try fsck'ing a 608GB news spool with ext2. NOT!
All my thanks to you all who have developed reiserfs and supported us on the list.