Using ReiserFS and Linux
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:
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:
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
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.
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
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.
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
/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
# mount / -o remount,notail
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
In future articles, I hope to take a look at Reiser4, a completely new (and
incompatible) version of ReiserFS which sports some interesting new
Be sure to checkout the other articles in this series:
- Part 1: Journaling and ReiserFS
- Part 2: Using ReiserFS and Linux
- Part 3: Tmpfs and bind mounts
- Part 4: Introducing Ext3
- Part 5: Ext3 in action