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.
Important:
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/hdxy
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/hdc1 /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 (small) 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 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.
Repairing ReiserFS file system with reiserfsck
The idea and commands in this article submitted by Jacques Wagener via email. In his own words, “After nuking my partition by accident (and through my stupidity) I was really disappointed in myself, especially in losing my bookmarks and rss-feeds”. The following article is based upon our email communication. I am just putting them as an article.
We have already written about ext2/ext3 file repair using fsck and other utilities. Linux comes with different filesystems and different repair utilities. To repair a ReiserFS filesystem you need to run reiserfsck command, which is a checking tool for the ReiserFS filesystem (just like fsck command for ext2/ext3 file system).
Reiserfsck searches for a Reiserfs filesystem on a device, replays any necessary transactions, and either checks or repairs the file system. ReiserFS saves data or log in a special file for pending disk updates and later on it commit updates to disk resulting into very good filesystem consistency.
Step # 1: Install reiserfsck
You need to install reiserfsprogs package, which includes reiserfsck user level tools for ReiserFS filesystems.
# apt-get install reiserfsprogs
Or if you are using RedHat/Fedor Core Linux:
# yum install reiserfsprogs
Step # 2: Backup partition/disk
Take system down to runlevel 1.
# init 1
Unmount /dev/sda1 (if it is still mounted as read/write only):
# umount /dev/sda1; umount /dev/sda2
Before using any one of the following command you are strongly advised to make a backup copy of the whole partition using dd or ddrescue (recommended) command.
# ddrescue /dev/sda /dev/sdb
OR use dd command:
# dd if=/dev/sda of=/dev/sdb conv=noerror
Step # 3: Check filesystem consistency
Above command makes a backup of your drive. Next check filesystem consistency which will reports problem to you with the following command (assuming that /dev/sda1 is your partition):
# reiserfsck –check /dev/sda1
If you get an error Bad root block 0If you get following message:
Running with –rebuild-tree is required
Then you need to run following command rebuilds the entire filesystem tree using leaf nodes found on the device (this is nothing but indication of corrupted :
# reiserfsck –scan-whole-partition –rebuild-tree /dev/sda1
Where,
* –scan-whole-partition: This option causes –rebuild-tree to scan the whole partition but not only the used space on the partition. You should always use this option with –rebuild-tree.
* –check: Checks filesystem consistency and reports, but does not repair any corruption that it finds.
* –rebuild-tree: This option rebuilds the entire filesystem tree using leaf nodes found on the device. Once you passed this option, do not stop or interrupt building operating.
Recovering corrupted superblock
Each file system has a superblock, which contains information about file system such as:
* File system type
* Size
* Status
* Information about other metadata structures
If this information lost, you are in trouble (data loss) so Linux maintains multiple redundant copies of the superblock in every file system.
During check (reiserfsck –check /dev/sda1) if you get an error superblock was missing, use following command to fix superblock:
# reiserfsck –rebuild-sb /dev/sda1
Where,
* –rebuild-sb: This option recovers the superblock on a Reiserfs partition. Normally you only need this option if mount reports “read_super_block: can’t find a reiserfs file system”.
Caution: Do not run above command twice on same drive. You will damage your partition (data).
Final note
Next logical step is mount your partition /dev/sda1 and check for your data:
# mkdir -p /mnt/data
# mount /dev/sda1 /mnt/data
# cd /mnt/data
# ls
# ls lost+found/ -l
lost+found is a special directory where recovered files are kept by Linux/reiserfsck. You can examine these files and restore the data.
Better backup entire partition using tar or ssh session:
# tar cvf /dev/nst0 /mnt/data
OR use scp to dump data to remote system:
# scp -r /mnt/data you@myserver.com:/backup
Thanks
Manoj Chauhan