The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Funtoo Filesystem Guide, Part 2
Using ReiserFS and Linux
Introduction
In this article, I'll show you how to get ReiserFS running under a typical Linux distribution. I'll also share lots of technical information on a variety of topics, such as performance considerations and more. Since I'll be covering installation first, I recommend that you read this article in its entirety before following the installation instructions. That way, you'll have all the technical notes in the back of your head as you start getting ReiserFS running on your systems, allowing you to make any necessary adjustments along the way.
The Search For A Good Kernel
To enable ReiserFS on your system, you'll first need to find a suitable kernel. At the time this article was orginally written (way back in 2001,) finding a suitable kernel for running ReiserFS required some effort, as ReiserFS was still an experimental filesystem. However, these days ReiserFS is no longer considered to be experimental and it's quite easy to find a kernel that supports ReiserFS. Unfortunately, Red Hat has removed ReiserFS support from the official Red Hat Enterprise Linux kernel, but it available in the stock Linux kernel sources, as well as various RHEL-based kernels.
If for some reason you are using a 2.4 kernel version, try to avoid early revisions of the kernel and use something that is fairly recent, like 2.4.30 or higher.
Are You Ready?
The first step in using ReiserFS is to make sure that your kernel has ReiserFS support available. To do this, type:
cat /proc/filesystems
If you see "reiserfs" listed in the resultant list, then reiserfs support is currently available. You're ready to go!
Now, what happens if you don't see ReiserFS support listed? Well, it's possible that it's actually there, but available as a kernel module and not yet loaded. To see if this is the case, first become the root user if you aren't root already, and type:
# modprobe reiserfs
Was modprobe able to load the reiserfs module? Run the cat /proc/filesystems command again and see if reiserfs is in the list. If it is, great! If not, then it looks like you are going to need to either upgrade to a kernel with ReiserFS support or recompile your existing kernel, if you enjoy doing that kind of thing.
If you're up for recompiling your own kernel, here's how you'd go about enabling ReiserFS. First, type make menuconfig in your kernel source tree. Under the Code maturity level options section, make sure that the Prompt for development and/or incomplete code/drivers option is enabled if you are using a 2.4 kernel. Then, head over to the File systems section, and enable ReiserFS support. It's recommended that you enable ReiserFS support to be compiled directly into your kernel (not as a module.) You may enable the extra ReiserFS capabilities if you wish. Now, save your settings, compile your kernel (make dep (for kernel 2.4 only); make bzImage; make modules; make modules_install) and configure your boot loader to load the new ReiserFS-enabled kernel.
It's always a good idea to save your current kernel and configure your boot loader so that you can boot with your original kernel, just in case your new kernel doesn't work.
Installing the Tools
Now, before you potentially reboot with a brand-new, ReiserFS-enabled kernel, we need to make sure that you have the "reiserfsprogs" tools installed. Most modern distributions will have these tools available. To determine if they are installed, run the following command as root:
# reiserfsck
Was it found? If so, great! This means that the reiserfsprogs are installed and available. If they aren't available, I recommend using your distribution's package manager to track down these tools and install them. Once the tools are installed, now would be a good time to reboot to enable a new ReiserFS-enabled kernel if you installed one.
Creating and Mounting the Filesystem
Once rebooted, you'll be able to create a ReiserFS filesystem on an empty partition as follows:
# mkreiserfs /dev/sdxy
In the above example, /dev/hdxy should be a device node corresponding to a free partition. Mount it as you would any other filesystem:
# mkdir /mnt/reiser # mount /dev/hdxy /mnt/reiser
And, if you'd like to add a ReiserFS filesystem to your /etc/fstab file, simply set the freq and passno fields to 0, as follows:
/dev/sdc1 /home reiserfs defaults 0 0
From this point forward, your ReiserFS filesystems should act identically to their ext2 counterparts, except that you'll no longer need to worry about long fsck times, and overall performance will be much better -- especially for small files.
ReiserFS Technical Notes
Filesystem Stability
With a modern kernel, ReiserFS is generally just as reliable as ext2 or ext3. As with all filesystems, a spattering of older kernels had some filesystem corruption bugs in them and should be avoided. However, if you are relying on your Linux distribution's selection of kernels, then you should not experience any issues with ReiserFS.
No dump/restore
Yes, it's true; ReiserFS does not yet have a dump and restore implementation. If you want to user ReiserFS and happen to be a dump fan, you'll have to find some alternate way of backing data. In reality, this turns out to be a non-issue, since 2.4+ kernels are incompatible with dump and restore in the first place. For more information on the dump/kernel incompatibility, read the LKML posting by Linus Torvalds where he says that "Dump was a stupid program in the first place. Leave it behind."
Performance Issues
While ReiserFS generally blows the socks off ext2, ReiserFS does have a few special-case performance weaknesses. The first is sparse file performance. ReiserFS sparse file performance will be significantly worse than ext2. This will change at some point, when the Namesys developers get around to optimizing that part of ReiserFS for ReiserFS 4. Until then, ext2 is a better solution for applications that place heavy demands on sparse files.
Performance Tweaks
Fortunately, there are a couple of easy general performance tweaks you can use to make these problems less severe. The first is to mount your ReiserFS filesystem with the `noatime` mount option (a mount option that's available for other filesystems as well as ReiserFS). As you probably know, UNIX systems record an atime, or access time, for each object on the filesystem that gets updated every time a file is read. For most people, the atime stamp isn't very useful and hardly any applications (none I can think of) rely on the atime for any critical task. For this reason, it can usually be safely turned off, which gives a nice all-around performance boost. Generally, unless you specifically know that you need atime support, you should be mounting your filesystems with the noatime option. Use an `/etc/fstab` entry like this:
/dev/hdc1 /home reiserfs noatime 0 0
In my first ReiserFS article, I mentioned that ReiserFS has a special feature
called "tail packing". In ReiserFS lingo, "tails" are files
that are smaller than a filesystem block (4k) or the trailing portions of files
that don't quite fill up a complete filesystem block. ReiserFS has really
excellent small-file performance because it is able to incorporate these tails
into its b*tree (its primary organizational data structure) so that they are
really close to the stat-data (ReiserFS' equivalent of an i-node). However,
since tails don't fill up a complete block, they can waste a lot of disk space
(relatively speaking, of course). To solve this problem, ReiserFS uses its
"tail packing" functionality to squish tails into as small a space as
possible. Generally, this allows a ReiserFS filesystem to hold around 5% more
than an equivalent ext2 filesystem.
Tail Packing Pros and Cons
However, tail packing also has its disadvantages. For one, it does give you a small but significant performance hit. Fortunately, the ReiserFS guys anticipated that some people would be willing to sacrifice around 5% of their disk capacity for a little extra performance, so they created the notail mount option. When a filesystem is mounted with this option, tail packing will be turned off, giving you greater speed and less storage capacity. In general, filesystem performance freaks mount their filesystems with both notail and noatime enabled, producing a noticeable performance improvement:
/dev/hdc1 /home reiserfs noatime,notail 0 0
Even if you want to save some disk space, there are times when temporarily mounting your filesystem with the notail option can be a good thing. In particular, some older boot-loaders have problems loading kernels that were created on a ReiserFS filesystem with tail packing enabled. If you're using a LILO earlier than version 21.6, you'll have this problem. You will also have problems with old versions of GRUB, which will not be able to load its stage1 and stage1_5 files. If you're already experiencing this problem, you can fix it by mounting the filesystem with the notail option, moving the files to another filesystem, and then moving them back. When they're recreated, they won't have tails. Also, remember that you can easily remount a filesystem (with new options) without unmounting it. This particular example remounts the root filesystem with the notail option:
# mount / -o remount,notail
Conclusion
I've found ReiserFS to be a truly incredible filesystem, offering oodles of small file performance and great (normally better than ext2) regular file performance. For example, updates to source code repositories using cvs and ReiserFS have been observed to complete in only fifteen seconds, where the same source code tree takes about two minutes to update with ext2. ReiserFS makes many peoples' lives more pleasant, and allows servers to handle large amounts of simultaneous IO without thrashing hard drives and negatively affecting interactive performance.
In future articles, I hope to take a look at Reiser4, a completely new (and incompatible) version of ReiserFS which sports some interesting new capabilities.
Resources
Be sure to checkout the other articles in this series: