Whether you are new to Linux or have been using it since you were in nappies, the amount of choice you have in this environment cannot but make you rack your brains: aside from the battle of operating system distributions, which are so diverse that practically everybody can find the one to fit their taste and needs, for years there has been a ferocious combat between a variety of file systems. Although ext is not giving up its position as a top dog (by the way, mostly owing to some historical factors, not because it is simply the best file system of all, if there is actually best anything), there are still a good deal of file system options that are worth considering, at least for some purposes. And ReiserFS is not an exception, as, like all file systems, it also has something up its sleeve. That’s why you would probably want to have a grasp of how it operates and its major strengths and weaknesses.
ReiserFS was developed by Hans Reiser and his team at Namesys in 2001. They cherished the idea of creating a revolutionary file system that would significantly differ from the available ones in being able to straightforwardly interact with the end user, who often has to take the trouble inventing various hacks or performing rainy dances to make the file system work exactly as he/she wants it to. Having been introduced with version 2.4.1 of the Linux kernel, ReiserFS goes by default in the Elive, Xandros, Slackware, Linspire, and YOPER distributions. It also used to be the major file system for SUSE Linux Enterprise, but in 2006 Novell decided to move to ext3.
Any ReiserFS-formatted partition is divided into many blocks of a fixed size. The file system itself consists of two areas: system and data. The system area includes the superblock with the most important details about the whole partition (for example, the block size), the bitmap containing information about free blocks and the journal, which describes all modifications made to the file system.
The data area is organized in a special linked structure called a balanced tree or simply B+ tree. Such a tree is comprised of nodes, each representing a block on the disk. The nodes can be of two types: internal and leaf. Internal nodes contain just pointers to their child nodes. Leaf nodes are located at the lowest level of the tree (i.e have no child nodes of their own) and incorporate “items” which hold actual data: stat items precede all files and directories and are used for metadata, directory items describe directories, direct items keep small files that fit in a single block while indirect items contain pointers to the blocks belonging to larger files. Any item has its own unique key which helps to identify and quickly locate it in the tree. Each node, regardless of its type, starts with a block header, which contains the information about the number of items in the block it refers to, free space left in it and which level of the tree it can be found at.
A file that is smaller than a single block is called a tail. Such tails are packed together and stored in a block so that they could fill its entire space, each occupying the exact amount it needs: in contrast to other file systems, in which, no matter how teeny, a file will consume at least one block, with “tail packing”, ReiserFS manages to save scores of storage space and keep high performance when dealing with small files. Among other advantages of this file system are:
Faster disk access. As direct items, which keep small files, and stat items describing them, are stored next to each other, such files can be read through a single input/output operation, therefore, to retrieve all the needed information a disk has to be accessed only once.
Immediate recovery after a crash. All metadata changes are written to the system journal, thus, after a blackout or unexpected system shutdown, the consistency of the file system can be resumed in a matter of seconds.
Data safety. In addition to metadata journaling, ReiserFS supports user data journaling, though it is not enabled by default as it can slow the system down. However, when a journal is employed for user data, it can be guaranteed that not only metadata but also your files are kept in a consistent state. On top of that, if you accidentally delete something important or reformat the partition, the data has very high chances (up to 100%) to be fully recovered with the help of a data recovery tool, for example, Raise Data Recovery for Linux or UFS Explorer Standard Recovery.
Live resizing. ReiserFS-formatted partitions can be resized while being in use.
High performance for large directories. The use of the B+ tree structure in ReiserFS improves its performance in case of handling very large directories and removes the limit on the number of files a single directory can contain.
Of course, like any technology, ReiserFS also has its weak spots:
Speed. Tail packing provokes a noticeable performance hit as when files are modified, the data needs to be repacked. Thus, this feature can be turned off, but then you will sacrifice storage capacity.
Scarce support and absence of modern features. ReiserFS is a relatively old file system. Excluding critical bug fixes and security updates, its development was stopped back in 2004 in favor of Reiser4. Reiser4 was intended to be fundamentally different from its predecessor and add many of the features it lacked, like delayed allocation and the support of plug-ins which allow enriching its functionality, i.e. enable compression or encryption. The project was very promising, but before the file system was even added to the main kernel, its lead designer, Hans Reiser, was convicted of murder and sent to prison in 2008, leaving its future up in the air. The Namesys company ceased to exist, and although some volunteers continue updating Reiser4, it is long odds that it will be merged into Linux kernel mainline, especially without corporate sponsorship.
In sum, the Reiser File System is unequaled in terms of speed as well as space utilization when there is a need to store and handle a big number of small files. However, the future of the file system is somewhat bleak, mainly because of the legal troubles of its author, that is why only time will tell whether it will end up in the main kernel or in the dustbin of history.