Difference between pages "Funtoo Filesystem Guide, Part 1" and "Funtoo Filesystem Guide, Part 2"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
{{Article
{{Article
|Author=Drobbins
|Author=Drobbins
|Next in Series=Funtoo Filesystem Guide, Part 2
|Previous in Series=Funtoo Filesystem Guide, Part 1
|Next in Series=Funtoo Filesystem Guide, Part 3
}}
}}
== Journaling and ReiserFS ==
== Using ReiserFS and Linux ==


=== What's in Store ===
=== Introduction ===
The purpose of this series is to give you a solid, practical introduction to Linux's various new filesystems, including ReiserFS, XFS, JFS, GFS, ext3 and others. I want to equip you with the necessary practical knowledge you need to actually start using these filesystems. My goal is to help you avoid as many potential pitfalls as possible; this means that we're going to take a careful look at filesystem stability, performance issues (both good and bad), any negative application interactions that you should be aware of, the best kernel/patch combinations, and more. Consider this series an "insider's guide" to these next-generation filesystems.
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.


So, that's what's in store. But to begin this series, I'm going to diverge from this plan for just one article and prepare you for the journey ahead. I'll cover two topics very important to the Linux development community -- journaling, and the design vision behind ReiserFS. Journaling is very important because it's a technology that we've been anticipating for a long time, and it's finally here. It's used in ReiserFS, XFS, JFS, ext3 and GFS. It's important to understand exactly what journaling does and why Linux needs it. Even if you have a good grasp of journaling, I hope that my journaling intro will serve as a good model for explaining the technology to others, something that'll be common practice as departments and organizations worldwide begin transitioning to these new journaling filesystems. Often, this process begins with a "Linux guy/gal" such as yourself convincing others that it's the right thing to do.
=== 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.


In the second half of this article, we're going to take a look at the design vision behind ReiserFS. By doing so, we're going to get a good grasp on the fact that these new filesystems aren't just about doing the same old thing a bit faster. They also allow us to do things in ways that simply weren't possible before. Developers, keep this in mind as you read this series. The capabilities of these new filesystems will likely affect how you code your future Linux software development projects.
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.


=== Understanding Journaling: Meta-data ===
=== Are You Ready? ===
As you well know, filesystems exist to allow you to store, retrieve and manipulate data. And, in order to do this, a filesystem needs to maintain an internal data structure that keeps all your data organized and readily accessible. This internal data structure (literally, "the data about the data") is called meta-data. It is the structure of this meta-data that gives a filesystem its particular identity and performance characteristics.
The first step in using ReiserFS is to make sure that your kernel has ReiserFS support available. To do this, type:
<pre>
cat /proc/filesystems
</pre>
If you see "reiserfs" listed in the resultant list, then reiserfs support is currently available. You're ready to go!


Normally, we don't interact with a filesystem's meta-data directly. Instead, a specific Linux filesystem driver takes care of that job for us. A Linux filesystem driver is specially written to manipulate this maze of meta-data. However, in order for the filesystem driver to work properly, it has one important requirement; it expects to find the meta-data in some kind of reasonable, consistent, non-corrupted state. Otherwise, the filesystem driver won't be able to understand or manipulate the meta-data, and you won't be able to access your files.
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:
<pre>
# modprobe reiserfs
</pre>
Was modprobe able to load the reiserfs module? Run the <span style="color:green">cat /proc/filesystems</span> 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.


=== Understanding Journaling: fsck ===
If you're up for recompiling your own kernel, here's how you'd go about enabling ReiserFS. First, type <span style="color:green">make menuconfig</span> 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 (<span style="color:green">make dep</span> (for kernel 2.4 only); <span style="color:green">make bzImage; make modules; make modules_install</span>) and configure your boot loader to load the new ReiserFS-enabled kernel.
This is where <span style="color:green">fsck</span> comes in. When a Linux system boots, <span style="color:green">fsck</span> starts up and scans all local filesystems listed in the system's '''/etc/fstab''' file. <span style="color:green">fsck</span>'s job is to ensure that the to-be-mounted filesystems' meta-data is in a usable state. Most of the time, it is. When Linux shuts down, it carefully flushes all cached data to disk and ensures that the filesystem is cleanly unmounted, so that it's ready for use when the system starts up again. Typically, <span style="color:green">fsck</span> scans the to-be-mounted filesystems and finds that they were cleanly unmounted, and makes the reasonable assumption that all meta-data is OK.


However, we all know that every now and then, something atypical happens, such as an unexpected power failure or system lock-up. When these unfortunate situations occur, Linux doesn't have the opportunity to cleanly unmount the filesystem. When the system is rebooted and <span style="color:green">fsck</span> starts its scan, it detects that these filesystems were not cleanly unmounted and makes a reasonable assumption that the filesystems probably aren't ready to be seen by the Linux filesystem drivers. It's very likely that the meta-data is messed up in some way.
{{fancyimportant|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.}}


So, to fix this situation, <span style="color:green">fsck</span> will begin an exhaustive scan and sanity check on the meta-data, correcting any errors that it finds along the way. Once fsck is complete, the filesystem is ready for use. Although some recently-modified data may have been lost due to the unexpected power failure or system lockup, since the meta-data is now consistent, the filesystem is ready to be mounted and be put to use.
=== 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:
<pre>
# reiserfsck
</pre>
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.


=== The Problem With fsck ===
=== Creating and Mounting the Filesystem ===
So far, this may not sound like a bad approach to ensuring filesystem consistency, but the solution isn't optimal. Problems arise from the fact that <span style="color:green">fsck</span> must scan a filesystem's entire meta-data in order to ensure filesystem consistency. Doing a complete consistency check on all meta-data is a time-consuming task in itself, normally taking at least several minutes to complete. Even worse, the bigger the filesystem, the longer this exhaustive scan takes. This is a big problem, because while <span style="color:green">fsck</span> is doing its thing, your Linux system is effectively offline, and if you have a large amount of filesystem storage, your system could be <span style="color:green">fsck</span>-ing for half an hour or more. Of course, standard <span style="color:green">fsck</span> behavior can have devastating results in mission-critical datacenter environments where system uptime is extremely important. Fortunately, there's a better solution.
Once rebooted, you'll be able to create a ReiserFS filesystem on an empty partition as follows:
<pre>
# mkreiserfs /dev/sdxy
</pre>
In the above example, '''/dev/hdxy''' should be a device node corresponding to a free partition. Mount it as you would any other filesystem:
<pre>
# mkdir /mnt/reiser
# mount /dev/hdxy /mnt/reiser
</pre>
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:
<pre>
/dev/sdc1  /home  reiserfs  defaults  0  0
</pre>
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.


=== The Journal ===
== ReiserFS Technical Notes ==
Journaling filesystems solve this <span style="color:green">fsck</span> problem by adding a new data structure, called a journal, to the mix. This journal is an on-disk structure. Before the filesystem driver makes any changes to the meta-data, it writes an entry to the journal that describes what it's about to do. Then, it goes ahead and modifies the meta-data. By doing so, a journaling filesystem maintains a log of recent meta-data modifications, and this comes in handy when it comes time to check the consistency of a filesystem that wasn't cleanly unmounted.


Think of journaling filesystems this way -- in addition to storing data (your stuff) and meta-data (the data about the stuff), they also have a journal, which you could call meta-meta-data (the data about the data about the stuff).
=== Filesystem Stability ===


=== Journaling in Action ===
With a modern kernel, ReiserFS is generally just as reliable as ext2 or ext3.
So, what does <span style="color:green">fsck</span> do with a journaling filesystem? Actually, normally, it does nothing. It simply ignores the filesystem and allows it to be mounted. The real magic behind quickly restoring the filesystem to a consistent state is found in the Linux filesystem driver. When the filesystem is mounted, the Linux filesystem driver checks to see whether the filesystem is OK. If for some reason it isn't, then the meta-data needs to be fixed, but instead of performing an exhaustive meta-data scan (like <span style="color:green">fsck</span>) it instead takes a look at the journal. Since the journal contains a chronological log of all recent meta-data changes, it simply inspects those portions of the meta-data that have been recently modified. Thus, it is able to bring the filesystem back to a consistent state in a matter of seconds. And unlike the more traditional approach that <span style="color:green">fsck</span> takes, this journal replaying process does not take longer on larger filesystems. Thanks to the journal, hundreds of Gigabytes of filesystem meta-data can be brought to a consistent state almost instantaneously.
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.


=== ReiserFS ===
=== No dump/restore ===
Now, we come to ReiserFS, the first of several journaling filesystems we're going to be investigating. ReiserFS 3.6.x (the version included as part of Linux 2.4+) is designed and developed by Hans Reiser and his team of developers at Namesys. Hans and his team share the philosophy that the best filesystems are those that help create a single shared environment, or namespace, where applications can interact more directly, efficiently and powerfully. To do this, a filesystem should meet the performance and feature needs of its users. That way, users can continue using the filesystem directly rather than building special-purpose layers that run on top of the filesystem, such as databases and the like.


=== Small File Performance ===
Yes, it's true; ReiserFS does not yet have a <tt>dump</tt> and <tt>restore</tt>
So, how does one go about making the filesystem more accommodating? Namesys has decided to focus on one aspect of the filesystem, at least initially -- small file performance. In general, filesystems like ext2 and ufs don't do very well in this area, often forcing developers to turn to databases or special organizational hacks to get the kind of performance they need. Over time, this kind of "I'll code around the problem" approach encourages code bloat and lots of incompatible special-purpose APIs, which isn't a good thing.
implementation. If you want to user ReiserFS and happen to be a <tt>dump</tt>
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
<tt>dump</tt> and <tt>restore</tt> in the first place. For more information on
the dump/kernel incompatibility, read the LKML posting by Linus Torvalds where
he says that &quot;Dump was a stupid program in the first place. Leave it
behind.&quot;


Here's an example of how ext2 can tend to encourage this kind of programming. ext2 is good at storing lots of twenty-plus k files, but isn't an ideal technology for storing 2,000 50-byte files. Not only does performance drop significantly when ext2 has to deal with extremely small files, but storage efficiency drops as well, since ext2 allocates space in either one or four k chunks (configurable when the filesystem is created).
=== Performance Issues ===


Now, conventional wisdom would say that you aren't supposed to store that many ridiculously small files on a filesystem. Instead, they should be stored in some kind of database that runs above the filesystem. In reply, Hans Reiser would point out that whenever you need to build a layer on top of the filesystem, it means that the filesystem isn't meeting your needs. If the filesystem met your needs, then you could avoid using a special-purpose solution in the first place. You would thus save development time and eliminate the code bloat that you would have created by hand-rolling your own proprietary storage or caching mechanism, interfacing with a database library, etc.
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.


Well, that's the theory. But how good is ReiserFS' small file performance in practice? Amazingly good. In fact, ReiserFS is around eight to fifteen times faster than ext2 when handling files smaller than one k in size! Even better, these performance improvements don't come at the expense of performance for other file types. In general, ReiserFS outperforms ext2 in nearly every area, but really shines when it comes to handling small files.
=== Performance Tweaks ===


=== ReiserFS Technology ===
Fortunately, there are a couple of easy general performance tweaks you can use
So how does ReiserFS go about offering such excellent small file performance? ReiserFS uses a specially optimized b* balanced tree (one per filesystem) to organize all filesystem data. This in itself offers a nice performance boost, as well as easing artificial restrictions on filesystem layouts. It's now possible to have a directory that contains 100,000 other directories, for example. Another benefit of using a b*tree is that ReiserFS, like most other next-generation filesystems, dynamically allocates inodes as needed rather than creating a fixed set of inodes at filesystem creation time. This helps the filesystem to be more flexible to the various storage requirements that may be thrown at it, while at the same time allowing for some additional space-efficiency.
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:


ReiserFS also has a host of features aimed specifically at improving small file performance. Unlike ext2, ReiserFS doesn't allocate storage space in fixed one k or four k blocks. Instead, it can allocate the exact size it needs. And ReiserFS also includes some special optimizations centered around tails, a name for files and end portions of files that are smaller than a filesystem block. In order to increase performance, ReiserFS is able to store files inside the b*tree leaf nodes themselves, rather than storing the data somewhere else on the disk and pointing to it.
<pre>/dev/hdc1  /home  reiserfs  noatime  0  0</pre>


This does two things. First, it dramatically increases small file performance. Since the file data and the stat_data (inode) information are stored right next to each other, they can normally be read with a single disk IO operation. Second, ReiserFS is able to pack the tails together, saving a lot of space. In fact, a ReiserFS filesystem with tail packing enabled (the default) can store six percent more data than the equivalent ext2 filesystem, which is amazing in itself.


However, tail packing does cause a slight performance hit since it forces ReiserFS to repack data as files are modified. For this reason, ReiserFS tail packing can be turned off, allowing the administrator to choose between good speed and space efficiency, or opt for even more speed at the cost of some storage capacity.
In my first ReiserFS article, I mentioned that ReiserFS has a special feature
called &quot;tail packing&quot;. In ReiserFS lingo, &quot;tails&quot; 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
&quot;tail packing&quot; 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.


ReiserFS truly is an excellent filesystem. In my next article, I'll guide you through the process of setting up ReiserFS under Linux. We'll also take a close look at performance tuning, application interactions (and how to work around them), the best kernels to use, and more.
=== 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
<tt>notail</tt> 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 <tt>notail</tt> and <tt>noatime</tt> enabled, producing a noticeable
performance improvement:
 
<pre>/dev/hdc1  /home  reiserfs  noatime,notail  0  0</pre>
 
Even if you want to save some disk space, there are times when temporarily
mounting your filesystem with the <tt>notail</tt> 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
<tt>stage1</tt> and <tt>stage1_5</tt> files. If you're already experiencing
this problem, you can fix it by mounting the filesystem with the
<tt>notail</tt> 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 <tt>notail</tt>
option:
 
<pre># mount / -o remount,notail</pre>
 
== 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 ==
== Resources ==

Revision as of 08:53, December 28, 2014

   Support Funtoo!
Get an awesome Funtoo container and support Funtoo! See Funtoo Containers for more information.

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.

   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/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:

   Tip

Read the next article in this series: Funtoo Filesystem Guide, Part 3

   Note

Browse all our available articles below. Use the search field to search for topics and keywords in real-time.

Article Subtitle
Article Subtitle
Awk by Example, Part 1 An intro to the great language with the strange name
Awk by Example, Part 2 Records, loops, and arrays
Awk by Example, Part 3 String functions and ... checkbooks?
Bash by Example, Part 1 Fundamental programming in the Bourne again shell (bash)
Bash by Example, Part 2 More bash programming fundamentals
Bash by Example, Part 3 Exploring the ebuild system
BTRFS Fun
Funtoo Filesystem Guide, Part 1 Journaling and ReiserFS
Funtoo Filesystem Guide, Part 2 Using ReiserFS and Linux
Funtoo Filesystem Guide, Part 3 Tmpfs and Bind Mounts
Funtoo Filesystem Guide, Part 4 Introducing Ext3
Funtoo Filesystem Guide, Part 5 Ext3 in Action
GUID Booting Guide
Learning Linux LVM, Part 1 Storage management magic with Logical Volume Management
Learning Linux LVM, Part 2 The cvs.gentoo.org upgrade
Libvirt
Linux Fundamentals, Part 1
Linux Fundamentals, Part 2
Linux Fundamentals, Part 3
Linux Fundamentals, Part 4
LVM Fun
Making the Distribution, Part 1
Making the Distribution, Part 2
Making the Distribution, Part 3
Maximum Swappage Getting the most out of swap
On screen annotation Write on top of apps on your screen
OpenSSH Key Management, Part 1 Understanding RSA/DSA Authentication
OpenSSH Key Management, Part 2 Introducing ssh-agent and keychain
OpenSSH Key Management, Part 3 Agent Forwarding
Partition Planning Tips Keeping things organized on disk
Partitioning in Action, Part 1 Moving /home
Partitioning in Action, Part 2 Consolidating data
POSIX Threads Explained, Part 1 A simple and nimble tool for memory sharing
POSIX Threads Explained, Part 2
POSIX Threads Explained, Part 3 Improve efficiency with condition variables
Sed by Example, Part 1
Sed by Example, Part 2
Sed by Example, Part 3
Successful booting with UUID Guide to use UUID for consistent booting.
The Gentoo.org Redesign, Part 1 A site reborn
The Gentoo.org Redesign, Part 2 The Documentation System
The Gentoo.org Redesign, Part 3 The New Main Pages
The Gentoo.org Redesign, Part 4 The Final Touch of XML
Traffic Control
Windows 10 Virtualization with KVM