ReiserFS

ReiserFS

Developer(s)	Namesys
Full name	ReiserFS
Introduced	2001 with Linux 2.4.1
Partition IDs	Apple_UNIX_SVR2 (Apple Partition Map) 0x83 (MBR) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT)
Structures
Directory contents	B+ tree
File allocation	Bitmap [1]
Limits
Max volume size	16 TiB [2]
Max file size	8 TiB [3]
Max no. of files	232 (~4 billion) [4]
Allowed filename characters	All bytes except NUL and '/'
Features
Dates recorded	modification (mtime), metadata change (ctime), access (atime)
Date range	December 14, 1901 - January 18, 2038
Forks	Extended attributes
File system permissions	Unix permissions, ACLs and arbitrary security attributes
Transparent compression	No
Transparent encryption	No
Other
Supported operating systems	Linux

ReiserFS is a general-purpose, journaled computer file system designed and implemented by a team at Namesys led by Hans Reiser who is referred to as the project's Benevolent Dictator for Life. ReiserFS is currently supported on Linux and may be included in other operating systems in the future. Introduced in version 2.4.1 of the Linux kernel, it was the first journaling file system to be included in the standard kernel. ReiserFS is the default filesystem on the Slackware, Xandros, Yoper, Linspire, GoboLinux, Kurumin Linux, FTOSX and Libranet Linux distributions. ReiserFS had been the default filesystem in Novell's SUSE Linux Enterprise until their decision to move to ext3 on October 12, 2006, two days after principal author Hans Reiser was charged with the murder of his wife.

Namesys considers ReiserFS (now occasionally referred to as Reiser3) stable and feature-complete and with the exception of security updates and critical bug fixes, has thus ceased development on it to concentrate on its successor, Reiser4.

A very extensive website can be found at Namesys[5] describing it, with diagrams and detailed explanations of its algorithms and benchmarks.

Features

At the time of its introduction, ReiserFS offered features then unseen in existing Linux filesystems:

• Metadata-only journaling (also block journaling, since Linux 2.6.8), its most-publicised advantage over what was the stock Linux file system at the time, ext2.
• Online resizing (growth only), with an underlying volume manager such as LVM. Since then, Namesys has also provided tools to resize (both grow and shrink) ReiserFS filesystems offline.
• Tail packing, a scheme to reduce internal fragmentation. Tail packing, however, can have a significant performance impact. Namesys recommends disabling the feature in performance-critical applications. Reiser4 may have improved this by packing tails where it doesn't hurt performance.

Performance

Compared to ext2 and ext3 in version 2.4 of the Linux kernel, when dealing with files under 4 KiB and with tail packing enabled, ReiserFS is often faster by a factor of 10–15. This is of great benefit in Usenet news spools, HTTP caches, mail delivery systems and other applications where performance with small files is critical.

Criticism

Some directory operations (including unlink(2)) are not synchronous on ReiserFS, which can result in race conditions with applications relying heavily on file-based locks (such as mail transfer agents qmail and Postfix).

There are no programs to specifically defragment a ReiserFS filesystem, although tools have been written to automatically copy the contents of fragmented files hoping that more contiguous blocks of free space can be found. However Reiser4 will have a repacker that takes care of optimizing file fragmentation.

fsck

Something that has attracted much criticism is the tree rebuild process of ReiserFS fsck: If the filesystem becomes so badly corrupt that the filesystem internal tree is unusable, a tree rebuild operation can be performed which may even further corrupt existing files on it, or introduce new entries with unexpected contents . This action, however, is not part of normal operation or a normal filesystem check and has to be explicitly initiated and confirmed by the administrator.

Nevertheless it is recommended not to store ReiserFS v3 images on a ReiserFS v3 partition (e.g. backups or disk images for emulators) without transforming them to a form that avoids misleading the filesystem, e.g., by compressing or encrypting. Reformatting an existing ReiserFS v3 partition can also leave data behind that could confuse the rebuild operation, resulting e.g. in files from the old filesystem reappearing after a tree rebuild. Note that this also opens an opportunity for malicious users to intentionally store files that will confuse the rebuilder. As the metadata is always in a consistent state after a filesystem check, corruption here means contents of files being merged in unexpected ways with the contained filesystem's metadata. The ReiserFS successor, Reiser4, fixes this problem.

Earlier issues

ReiserFS in versions of the Linux kernel before 2.4.16 were considered unstable by Namesys and not recommended for production use, especially in conjunction with NFS.

Early implementations of ReiserFS (prior to that in Linux 2.6.2) were also susceptible to out-of-order write hazards (files being appended to during a crash, for example, would gain a tail of garbage upon next mount). The current journaling implementation in ReiserFS, however, is now on par with that of ext3's "ordered" journaling level.

Design

ReiserFS stores file metadata ("stat items"), directory entries ("directory items"), inode block lists ("indirect items"), and tails of files ("direct items") in a single, combined B+ tree keyed by a universal object ID. Disk blocks allocated to nodes of the tree are "formatted internal blocks". Blocks for leaf nodes (in which items are packed end-to-end) are "formatted leaf blocks". All other blocks are "unformatted blocks" containing file contents. Directory items with too many entries or indirect items which are too long to fit into a node spill over into the right leaf neighbour. Block allocation is tracked by free space bitmaps in fixed locations.

By contrast, ext2 and other Berkeley FFS-like filesystems simply use a fixed formula for computing inode locations, hence limiting the number of files they may contain. Most such filesystems also store directories as simple lists of entries, which makes directory lookups and updates linear time operations and degrades performance on very large directories. The single B+ tree design in ReiserFS avoids both of these problems due to better scalability properties.

See also

• Comparison of file systems
• Reiser4
• Namesys

External links

• Namesys
• Theodore Ts'o critiques the ReiserFS block journaling implementation
• convertfs, a utility which performs in-place conversion between any two filesystems with sparse file support
• An overview of the ReiserFS on-disk format
• Florian Buchholz's The structure of the Reiser file system, a very detailed description of the ReiserFS disk structures.
• rfstool - Limited Windows access for ReiserFS partitions.
• rfsgui - Windows GUI developed from rfstool code; Win32 and x64 builds available.
• LTOOLS Windows GUI based on the rfstool code
• YAReG - Windows GUI using rfstool; read ReiserFS partitions in Windows
• Virtual Volumes - Another GUI which uses rfstools. This can also read ext2/ext3, LVM2, software RAID etc. This is the successor to Explore2fs
• ReiserDriver - A read-only file system driver to access ReiserFS partitions under Windows (development on hiatus).
• CrossMeta - Contains support for ReiserFS partitions on Windows.
• Gentoo Forum Link - Contains an interesting discussion of fragmentation in reiserFS, includes a script which measures fragmentation and links to a script that defragments quite well.