Adventure ReiserFSOne of the still most lively impressions of this year's Chemnitzer Linux Tag (ab out which you will be able to read more here later on) was the first contact with the relatively new Reiser-Filesystem by no doubt.
There you could look at the first experiments with computers running Linux with the ReiserFS instead of the quite classical ext2 filesystem.
Turning off the Linux-Computer...
...without a previous shutdown had, as you know, up to now the consequence, that
at the next system boot, every mounted ext2
has been checked for potential errors. Normally it was just an annoying process,
because it was extremely long lasting with huge
capacities. But this check now and then had the consequence of showing that the
filesystem is very inconsistent. This sometimes ended
Just as annoying with the filesystem check was, that it was dependent of a maxim
um mount count or a certain space of time.
(Standard: 6 months) All this is generally just annoying, but in reagrd to high-
availabilty servers it can bring enormous troubles in the
case of an however caused hangup.
For example, when half of a company cannot access their files because the server is occupied with the boot sequence (that can bring more difficulties, as you have already read above).
According to this, the call for an alternative is legal and a suitable solution for such problems seems to be the use of a so called journaling filesystem. As you might know, most of the ext2 filesystem problems o riginate because the operating system does not write data from opened files to disk immediately, but keeps them in the memory and wri tes them to disk later because of efficiency matters (- the disk is synchronized). Therefore, it is easy to imagine that after a crash s hort before such a synchronization some files (the opened and not yet written ones) arei a dubious state. This leads to a consistence chec k during the next boot, respectively the next filesystem check.
Exactly at this point, the journaling filesystem interferes: It is documented in a so called "journal", which files are currently in use or opened. Therewith it is clear in the case of a hangup, which files are in danger to be inconsistent and must be checked. It is easy to imagine, that the filesystem check and possible recovery jobs work much more fas ter...
On several commercial UNIX systems journaling file-systems have been in use for
a long time ( - just look at IRIX by SGI, whose
file-system, XFS, is being ported to a GPL base, meanwhile even to please the Li
nux community). But even on the Linux sector you
can find interesting approaches. At the moment the most discussed and most matur
e representative of this guild is ReiserFS, that was
created by Hans Reiser and meanwhile is developed with financial help of SuSE. I
t promises performance winnings by a modern way of
disk management besides the journaling aspects.
So it seems to be in time, to try out this test candidate.
First of all the following is to be noticed: The way to a Linux system with Reis erFS is quite long and uncomfortable at the moment (if you do not want to mess around with the installation of the current SuSE distributio n, which provides an installation directly into this file-system). Basically it works like following:
- The used Kernel must be patched for ReiserFS capability and compiled. (In the te st, 2.2.14 was used.) Afterwards, you should compile the ReiserFS-tools (especially mkreiserfs) and bring them into your system. The interference into the system is inevitable. So the ones who only use out of the box kernels and fear a self-configuration do not have ma ny chances.
- New partitions must be created and formated with ReiserFS, one for every file-sy stem that shall be converted from ext2 to ReiserFS. If the root file-system shall be put on ReiserFS, you will have to create a /boot p artition that is formatted with ext2. At the moment, LILO cannot boot the kernel from ReiserFS.
- At the end, all files from the old ext2-systems must be copied to the Reiser-sys tems. Afterwards, the system is customised to the new environment (editing fstab, perhaps reconfiguring LILO etc.) and newly booted. T hen you shall hope and pray that the programs and files have stood the brachial encroachment sanely.
To the battle...
In spite of (or just because) the uncomfortable installation the motto was to ac hieve a useable result this way. Indeed, no existing system was updated to ReiserFS, but a completely new installation was done. My favourit e distribution Stampede Linux 0.89 was used. And so we already were able to start...
The partition table of my previous installation has been widely retained. (Separ ate partitions for /, /home, and /usr, altogether approximately 7 GB.) A /boot - and a installation-partition for the base system have been added.
The system installation went without problems: As usual with Stampede, booting b y a boot- and a root-disk, then formatting the installation partition and a long forced pause, spent with reading of William Gi bson's "Idoru", while the installer put the *.slp packages of the system onto the harddisk. Because my whole mail-/usenet-/web-access takes pl ace in Linux and was not sure what to expect from the ReiserFS installation, my decision at this point of the installation was, to install the system completely, bring in the necessary software and allow frictionless operating in a normal environment. Afterwards cr eate a copy of this work system in the ReiserFS partition and test if it can fullfill my demands.
The next logical step was to update the system first and make it suitable for Re iserFS at the same time. That meant:
- Achieve actual kernel sources (2.2.14) and decompress them into /usr/src/linux
- Download the ReiserFS patch from the net (at installation time version 3.5.19) a nd put it to /usr/src because of simplicity, if necessary decompress it
- Bring in the patch to the kernel tree
- Activate ReiserFS support in the kernel
- Compile the kernel
- Copy the new kernel to /boot and reconfigure and reinstall LILO
- Create the ReiserFS utilities, that reside in /usr/src/linux/fs/reiserfs/utils, and copy the binaries to /sbin
That's it, for the moment. If everything went like planned, after re-booting the system
>> cat /proc/filesystemsshould show the entry reiserfs and the essential preparatory work should be done .
In my installation this was followed by bringing in and compiling some software, that is essential for my use (XFree 3.3.6), the installation of the ALSA drivers, and all tasks of post-installation until the system worked like expected.
Now let's go over to the quite critical part of the installation, the
Copying of the system
However, first of all some preparations: By "mkreiserfs" a file-system is create
d on the corresponding partitions, in the case of the
example installation these were /usr and / (/home remained on ext2 as a precauti
Equally, the /boot partition is formatted by "mke2fs". Furthermore, I decided to copy the (further on quite important) file /etc/fstab into the /root directory and to adapt the copy to the new environment (for the startabili ty of the newly installed system). Furthermore, another section in /etc/lilo.conf was added to be able to boot the new root partition an d the new LILO configuration was installed.
Prepared this way, then long lasting copy process could be started.
Step by step, /, /usr (with "-t reiserfs") and /boot (with "-t ext2") were mount ed on /mnt and the files where copied with "cp" or with a pipe with "tar", into the new partition. E.g.
>> (cd / && tar cplf - . --exclude boot --exclude usr) | ( cd /mnt && tar xpf - )
In closure (about 15 pages of "Idoru" later...) the fstab from /root was modifie d and put into /mnt/etc to its new location and the system was rebooted.
The first start
...went on totally unspectacularly: Besides of some small hurry errors in /etc/f stab, the copied system booted quickly and without any problems until the login screen. A glance on /etc/mtab showed the following:
thunderbird:cat /etc/mtab /dev/hdb1 / reiserfs rw 0 0 /dev/hda3 /usr reiserfs rw 0 0 /dev/hdb2 /boot ext2 ro 0 0 /dev/hda10 /home ext2 rw 0 0 /none /dev/pts devpts rw,gid=5,mode=620 0 0 proc /proc proc rw 0 0Therefore, the partitions were mounted regularly. This could be verified by some operations on the system: Everything was working fine.
Event brachial tests could not push the system out of tranquillity: Totally alik e, in which situation a system hang-up was simulated by pressing the reset button (Computing a TEX document with an active metafont, cop ying the /usr/doc directory to /tmp and so on), long lasting disk checks stood away and the system booted approximately with the same speed and without any problems. The long latency times, that ext2 would have brought with in that situations, were missing also l ike the jump to the single user mode to repair a partition.
Meanwhile, ReiserFS has been running for quite a month on my system and until no w, the results are very satisfying. The tests (measures), how the blessed performance winnings besides the journaling because of the improved disk management take effect and how the file-system looks after longer use, still remain. But ReiserFS has stood the first test...
...for reiserfs: First, there is ext3 as a logical successor of the current ext2
file-system, that is in early alpha stage according to the
developers and so cannot be used in a "productive" environment. In advantage, th
e copy process (described above) of the installed
distribution is obsolete when changing from ext2 to ext3 (only the journals for
every new ext3 partition must be installed manually). This
step can be easily cancelled, so that a test of this system will be done soon. I
f you are likely to experiment, you should be warned of
bringing in ext3 and reiserfs into the same kernel tree. Because of several equa
lities in the internal names, there would be heavy
Furthermore, the XFS-system mentioned above shall be mentioned. To say it cl early: XFS is the toughest and most proven alternative of all the named approaches. It also has been working for several ye ars (in SGI's IRIX system). Indeed, XFS has been open source only since a short time. At the moment it is being worked on changing the source code and removing possible patents and re-implementing the functions. Let's hope that the arising sources can hold the high level of the proprietary version. The last, possibly the youngest deployment in this row, JFS of "Big Blue" IBM, c urrently in version 0.0.1, has not yet reached an all day fitting maturity to be used on an adequately formatted disk: the skills of t he new system are currently restricted to a simple 'ls'. Time will show what approach will be put into use first. Development and testing must be done with all projects, but currently reiserfs is the most mature one.
Links und Information:
|www.linux-magazin.de||Homepage of the Linux Magazine. In issue 4/2000 an extensive artikel written by Bernhard Kuhn deals with this topic and shows more technical details.|
|http://devlinux.com/projects/reiserfs||ReiserFS-Page. Here you can find the patches, basics and much more other doc umentation|
|ftp://ftp.de.kernel.org/pub/linux||FTP server for downloading the current Linux kernel|
|http://oss.sgi.com/projects/xfs||SGI homesite for the XFS.|
|http://oss.software.ibm.com/developerworks/opensource/jfs/index.html||Homepage of the JFS|
|ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs||Download site for all who are interested in ext3.|
Enter Own Comment