ReiserFS

At the time of its introduction, ReiserFS offered features that had not been available in existing Linux file systems:

• Metadata-only journaling (also block journaling, since Linux 2.6.8), its most-publicized advantage over what was the stock Linux file system at the time, ext2.
• Online resizing (growth only), with or without an underlying volume manager such as LVM. Since then, Namesys has also provided tools to resize (both grow and shrink) ReiserFS file systems offline.
• Tail packing, a scheme to reduce internal fragmentation. Tail packing can have a significant performance impact. Reiser4 may have improved this by packing tails where it does not negatively affect performance.[6]

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 file systems of that time simply used a fixed formula for computing inode locations, hence limiting the number of files they may contain.[7] Most such file systems 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.

Regarding the development of a filesystem, three fields have to be considered separately:

• The on-disk format, thus the way data is structured on the media.
• The implementation of the filesystem driver, which enables the operating system to read and write data.
• The maintenance tools for creating, deleting, resizing, defragmenting and checking partitions on the media.

Therefore this section contains three tables: one for the 3.5.x series of the filesystem driver that was used to read and write the 3.5 on-disk format, another one for the 3.6.x series of the filsystem driver that is used to read and write the 3.6 on-disk format and a third one for the tools contained in the reiserfsprogs package.

Since the on-disk format 3.6 is regarded as feature complete and stable, it is frozen and doesn't get changed anymore. The filesystem driver for Linux, that is part of the official kernel as well as the reiserfsprogs operating in user space are still being maintained and getting updates (rarely also new features) even nowadays (as of 2019).

The defrag program was never fully implemented, although there were attempts up to the year 2014. One reason why it never was finished was the rise of solid state disks (SSD) which – contrary to the classic spinning wheel hard disk drives (HDD) – do not need to be defragmented, or more precisely: shouldn't be defragmented at all, as any unnecessary write operations will shorten the life of an SSD.

"The branch contains changes to quota code so that it does not modify persistent flags in inode->i_flags (it was the only place in kernel doing that) and handle it inside filesystem's quotaon/off handlers instead.
The branch also contains two UDF cleanups, a couple of reiserfs fixes and one fix for ext2 quota locking"

Compared with ext2 and ext3 in version 2.4 of the Linux kernel, when dealing with files under 4 KiB and with tail packing enabled, ReiserFS may[14] be faster. This was said to be of great benefit in Usenet news spools, HTTP caches, mail delivery systems, and other applications where performance with small files is critical. However, in practice news spools use a feature called cycbuf, which holds articles in one large file; fast HTTP caches and several revision control systems use a similar approach, nullifying these performance advantages. For email servers, ReiserFS was problematic due to semantic problems explained below. Also, ReiserFS had a problem with very fast filesystem aging when compared to other filesystems — in several usage scenarios filesystem performance decreased dramatically with time.

Before Linux 2.6.33,[15] ReiserFS heavily used the big kernel lock (BKL) — a global kernel-wide lock — which does not scale very well[16][17] for systems with multiple cores, as the critical code parts are only ever executed by one core at a time.

ReiserFS was the default file system in SuSE Linux since version 6.4 (released in 2000),[18][19] until switching to ext3 in SUSE Linux Enterprise 10.2/openSUSE 11, announced in 2006.[20][21]

Jeff Mahoney of SUSE wrote a post on 14 September 2006 proposing to move from ReiserFS to ext3 for the default installation file system.[16] Some reasons he mentioned were scalability, "performance problems with extended attributes and ACLs", "a small and shrinking development community", and that "Reiser4 is not an incremental update and requires a reformat, which is unreasonable for most people."[16] On October 4 he wrote a response comment on a blog in order to clear up some issues.[22] He wrote that his proposal for the switch was unrelated to Hans Reiser being under trial for murder.[23] Mahoney wrote he "was concerned that people would make a connection where none existed" and that "the timing is entirely coincidental and the motivation is unrelated."[22]

Some directory operations (including unlink(2)) are not synchronous on ReiserFS, which can result in data corruption with applications relying heavily on file-based locks (such as mail transfer agents qmail[24] and Postfix[25]) if the machine halts before it has synchronized the disk.[26]

There are no programs to specifically defragment a ReiserFS file system, 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, a "repacker" tool was planned for the next Reiser4 file system to deal with file fragmentation.[27] With the rise of Solid State Disks this problem became irrelevant as contrary to Hard Disk Drives there is no slow down caused by fragmentation as SSDs don't use any moving parts. It is even recommended to abstain from any kind of defragmentation on SSDs because it will shorten their lifetime.

• Reiser4
• List of file systems
• Comparison of file systems

• ReiserFS 3.6 at Linus Torvalds' Git repository – nowadays (2019) the main development resource of ReiserFS 3
• ReiserFS and Reiser4 wiki
• Namesys web site (archived version from 2007 October)
• Reiserfsprogs
• Theodore Ts'o critiques the ReiserFS block journaling implementation
• convertfs, a utility which performs in-place conversion between any two file systems 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 (archived version from 2011 November)
• Gentoo Forum Link – Discussion on ReiserFS fragmentation, including a script for measuring fragmentation and defragmenting files.
• Reiser4 Future Vision
• Windows utilities to access ReiserFS: RFSTOOL, YAReG – Yet Another R(eiser)FStool GUI, rfsd – ReiserDriver.
• Windows port of ReiserFS in CROSSMETA