Hubbry Logo
Reiser4Reiser4Main
Open search
Reiser4
Community hub
Reiser4
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Reiser4
Reiser4
Reiser4
View on Wikipedia
from Wikipedia
Reiser4
Developer(s)Edward Shishkin and others[1]
Full nameReiser4
Introduced2004; 22 years ago (2004) with Linux
Partition IDsApple_UNIX_SVR2 (Apple Partition Map)

0x83 (MBR)

Basic data partition (GPT)
Structures
Directory contentsDancing B*-tree
Limits
Max file size8 TiB on x86
Max filename length3976 bytes
Allowed filename
characters		All bytes except NUL and '/'
Features
Dates recordedmodification (mtime), metadata change (ctime), access (atime)
Date range64-bit timestamps[2]
ForksNo
File system
permissions		Unix permissions
Transparent
compression		Yes
Transparent
encryption		No
Data deduplicationNo
Other
Supported
operating systems		Linux
Websitereiser4.wiki.kernel.org
Repositorygithub.com/edward6/reiser4

Reiser4 is a computer file system, successor to the ReiserFS file system, developed from scratch by Namesys and sponsored by DARPA as well as Linspire. Reiser4 was named after its former lead developer Hans Reiser. As of 2021, the Reiser4 patch set is still being maintained,[3][4] but according to Phoronix, it is unlikely to be merged into mainline Linux without corporate backing.[5]

Features

[edit]

Some of the goals of the Reiser4 file system are:

  • Atomicity (filesystem operations either complete, or they do not, and they do not corrupt due to partially occurring)
  • Different transaction models: journaling, write-anywhere (copy-on-write), hybrid transaction model[6]
  • More efficient journaling through wandering logs
  • More efficient support of small files, in terms of disk space and speed through block suballocation
  • Liquid items (or virtual keys) – a special format of records in the storage tree, which completely resolves the problem of internal fragmentation
  • EOTTL (extents on the twig level) – fully balanced storage tree, meaning that all paths to objects are of equal length
  • Faster handling of directories with large numbers of files
  • Transparent compression: Lempel-Ziv-Oberhumer (LZO), zlib
  • Plugin infrastructure
  • Dynamically optimized disk-layout through allocate-on-flush (also called delayed allocation in XFS)
  • Delayed actions (tree balancing, compression, block allocation, local defragmentation)
  • R and D (Rare and Dense) caches, synchronized at commit time
  • Transactions support for user-defined integrity
  • Metadata and inline-data checksums[7]
  • Mirrors and failover[8]
  • Precise discard support[9] with delayed issuing of discard requests for SSD devices[10]

Some of the more advanced Reiser4 features (such as user-defined transactions) are also not available because of a lack of a VFS API for them.

At present Reiser4 lacks a few standard file system features, such as an online repacker (similar to the defragmentation utilities provided with other file systems). The creators of Reiser4 say they will implement these later, or sooner if someone pays them to do so.[11]

Performance

[edit]

Reiser4 uses B*-trees in conjunction with the dancing tree balancing approach, in which underpopulated nodes will not be merged until a flush to disk except under memory pressure or when a transaction completes. Such a system also allows Reiser4 to create files and directories without having to waste time and space through fixed blocks.

As of 2004, synthetic benchmarks performed by Namesys in 2003 show that Reiser4 is 10 to 15 times faster than its most serious competitor ext3 working on files smaller than 1 KiB. Namesys's benchmarks suggest it is typically twice the performance of ext3 for general-purpose filesystem usage patterns.[12] Other benchmarks from 2006 show results of Reiser4 being slower on many operations.[13] Benchmarks conducted in 2013 with Linux Kernel version 3.10 show that Reiser4 is considerably faster in various tests compared to in-kernel filesystems ext4, btrfs and XFS.[14]

Integration with Linux

[edit]

Reiser4 has patches for Linux 2.6, 3.x, 4.x and 5.x.,[15][3] but as of 2019, Reiser4 has not been merged into the mainline Linux kernel[3] and consequently is still not supported on many Linux distributions; however, its predecessor ReiserFS v3 has been widely adopted. Reiser4 is also available from Andrew Morton's -mm kernel sources, and from the Zen patch set. The Linux kernel developers claim that Reiser4 does not follow the Linux "coding style" by the decision to use its own plugin system,[16] but Hans Reiser suggested the decision was made for political reasons.[17] The latest released Reiser4 kernel patches and tools can be downloaded from Reiser4 project page at sourceforge.net.[4]

History of Reiser4

[edit]
See also: Hans Reiser

Hans Reiser was convicted of murder on April 28, 2008, leaving the future of Reiser4 uncertain. After his arrest, employees of Namesys were assured they would continue to work and that the events would not slow down the software development in the immediate future. In order to afford increasing legal fees, Hans Reiser announced on December 21, 2006, that he was going to sell Namesys;[18] as of March 26, 2008, it had not been sold, although the website was unavailable. During a CNET interview in January 2008, Edward Shishkin, an employee and programmer working for Namesys, said: "Commercial activity of Namesys has stopped." Shishkin and others continued the development of Reiser4,[19] making source code available from Shishkin's web site,[20] later relocated to kernel.org.[21] Since 2008, Namesys employees have received 100% of their sponsored funding from DARPA.[22][23][24]

In 2010, Phoronix wrote that Edward Shishkin was exploring options to get Reiser4 merged into Linux kernel mainline.[25] As of 2019, the file system is still being updated for new kernel releases, but has not been submitted for merging.[3] In 2015, Michael Larabel mentioned it is unlikely to happen without corporate backing,[26] and then he suggested in April 2019 that the main obstacle could be the renaming of Reiser4 so as to avoid any references to Reiser.[3]

Shishkin announced a Reiser5 filesystem on December 31, 2019.[27]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Reiser4

View on Grokipedia
from Grokipedia
Reiser4 is a general-purpose, for , developed from scratch by and the Namesys team as a successor to the earlier , with initial sponsorship from . It employs a balanced structure, often referred to as "dancing trees," for efficient data organization and access, along with a plugin-based that allows modular extensions for features like , compression, and custom item types. This design emphasizes atomic operations, multiple transaction models, and compact storage, achieving high performance in benchmarks for small-file workloads and metadata-intensive tasks while offering up to 94% storage efficiency through tail packing. Development of Reiser4 began in 2001, with early patches proposed for inclusion in the Linux 2.6 kernel series around 2003, highlighting its "wandering log" technique to reduce and support for multi-file transactions. Despite positive results and testing in Andrew Morton's -mm tree, ongoing debates among kernel developers centered on its innovative but controversial plugin system, which was seen as potentially complicating , compatibility, and long-term , as well as overlapping with (VFS) responsibilities. Concerns about code complexity, lack of certain features like direct I/O and extended attributes at the time, and interpersonal dynamics with ultimately prevented its merger into the mainline kernel. As an out-of-tree project, Reiser4 has been maintained through patches for various kernel versions, including upstream support up to 5.16 as of 2022 and community-maintained builds (such as from the project) for 5.17 as of October 2025, with utilities like mkfs.reiser4 and .reiser4 available for formatting and checking. However, upstream development has ceased, with no updates to its primary repository since 2022, and there is no support for modern 6.x kernels, rendering it unsuitable for production use without significant effort to port it to current kernels.

Core Concepts and Architecture

Design Goals and Innovations

Reiser4 was designed with a primary focus on optimizing performance and space efficiency for small files, particularly those under 1 KiB, which are common in metadata-heavy workloads such as systems and web servers. Traditional file systems often waste significant disk space by allocating full 4 KiB blocks to tiny files, leading to fragmentation and inefficiency. To address this, Reiser4 incorporates block suballocation, allowing multiple small files or file tails to share a single block, achieving approximately 94% space efficiency for small files and minimizing wasted space. This approach reduces fragmentation by enabling contiguous storage where possible through extent pointers, while supporting dynamic allocation without excessive overhead. A key innovation in Reiser4 is the use of dancing B*-trees for indexing, which provide balanced, adaptive structures that optimize for both read and write operations. Unlike traditional B+-trees that rebalance immediately, dancing trees defer balancing until disk flushes, improving caching efficiency by segregating frequently accessed pointers from less frequent objects, thus doubling read speeds compared to its predecessor Reiser3. This design shifts from rigid, fixed hierarchies to a more flexible object-based storage model, where files are treated as collections of items stored in nodes, allowing for semantic layering that separates user-visible naming from underlying performance optimizations. Additionally, Reiser4 emphasizes atomic file operations, ensuring that transactions either complete fully or not at all, which enhances consistency without requiring kernel recompilation for extensibility via plugins. The development of Reiser4 was sponsored by DARPA and Linspire, with the latter aiming to improve desktop performance for everyday workloads involving numerous small files. These sponsorships underscored the file system's goals of robustness and adaptability in diverse environments, from secure systems to consumer applications.

Key Data Structures

Reiser4 employs the Dancing B*-tree as its primary indexing structure, a variant of the B+-tree designed for efficient storage and retrieval of filesystem metadata and data. This structure organizes all filesystem objects in a single balanced tree, where internal nodes contain keys and pointers to child nodes, while leaf nodes hold the actual items. The Dancing B*-tree incorporates an adaptive balancing algorithm that defers node merging and splitting until a flush to disk, allowing temporary imbalances in memory to optimize caching and reduce immediate overhead during operations. Node rotation and repacking occur lazily during these flushes, rotating underpopulated or overpopulated nodes to maintain balance without frequent disk I/O, thereby supporting scalability for large numbers of objects through 64-bit object identifiers that enable up to 2^{64} entities. Central to Reiser4's object model are object items and stat , which provide a unified representation for files, directories, and other metadata as extensible objects within the Dancing leaves. Object items serve as containers for or metadata, sized to fit within a single node (typically 4 KiB), and can include extents for file bodies, indirect pointers for larger files, or direct for small files. Stat , stored as indivisible static_stat_data items, encapsulate core attributes such as ownership, permissions, timestamps, size, and link count for each object, dynamically allocated on disk as needed. This approach allows objects to integrate plugins for custom behaviors, such as compression or , while maintaining a consistent key-based addressing scheme that sorts items by object ID, type, and offset. File allocation in Reiser4 leverages suballocation within blocks to optimize for small files, packing up to 16 small objects into a single 4 KiB block through tail packing, where unused in a block accommodates tails of multiple files. For larger files, allocation uses contiguous extents aligned to 4 KiB boundaries, with pointers managed via item plugins to minimize fragmentation. mechanisms are integral to the allocation process, particularly through "copy-on-capture" during transactions, where modified blocks are copied before overwriting to ensure atomicity and enable potential snapshot functionality by retaining prior versions in the journal until commit. This suballocation and COW strategy aligns with Reiser4's design goals for efficient handling of small files by reducing wasted in partially filled blocks. Directories in Reiser4 are handled through a flat global of objects, where directories appear as specialized views over the Dancing rather than separate hierarchical structures, promoting efficiency in namespace management. Directory entries are stored as cmpnd_dir_item objects, linking names to object keys via hash-based lookups facilitated by pluggable hash functions that map directory names to file locations, enabling fast O(1) average-case retrieval even in large directories. This hash-driven approach sorts entries approximately lexicographically within tree nodes, minimizing collisions and supporting efficient traversal without full linear scans.

Features

Journaling and Atomic Operations

Reiser4 employs an asynchronous journaling mechanism to ensure and facilitate rapid crash recovery, changes in a way that allows operations to proceed without blocking the . This approach supports two primary modes: metadata journaling, which captures only structural changes to the such as directory entries and inode updates, and journaling, which additionally logs file content modifications for heightened consistency guarantees. These modes operate with ordered or writeback options; in ordered mode, data blocks are written to their final locations before corresponding metadata to prevent partial updates, while writeback mode permits metadata commits ahead of for better , relying on subsequent flushes. Central to Reiser4's design are atomic operations, implemented through "transcrashes"—collections of disk updates grouped into all-or-nothing transactions that either fully succeed or leave the unchanged in the event of a . For instance, operations like file creation, deletion, or renaming are encapsulated such that partial execution cannot result in inconsistencies, with dependencies between updates enforced to maintain . This atomicity extends to unformatted nodes, which represent raw file blocks not subject to journaling in metadata mode but integrated into transactions when journaling is enabled, allowing efficient packing without fixed formatting overhead. Upon system mount following a crash, Reiser4's replay process scans the journal for committed transactions—identified by commit records—and replays them by applying overwrite sets and deallocations, restoring the to a consistent state without extensive full-disk checks. Journal transactions are sized to balance atomicity with manageable replay overhead, enabling the use of wandering blocks that are allocated dynamically rather than from a fixed journal area. This mechanism ties briefly into techniques for node modifications, ensuring that in-flight changes do not corrupt the on-disk tree.

Plugins and Extensibility

Reiser4 features a highly modular plugin that promotes extensibility by allowing key behaviors to be customized through interchangeable components integrated into the kernel module. This design decouples specific implementations from the core logic, enabling developers to add or modify functionality such as data formatting, directory indexing, and allocation strategies without recompiling the kernel or altering the base code. The draws on object-based storage principles, where plugins operate on objects to handle diverse operations efficiently. The system incorporates multiple built-in plugins across several categories, with documentation indicating at least 24 metadata-related components supporting various operations. Item plugins manage the storage and retrieval of file and metadata, including specialized handlers for directories and indirect pointers that facilitate flexible extent management. Hash plugins provide functions for ordering directory entries to optimize lookups, while policy plugins govern decisions, such as whether to employ tail packing for small files or extents for larger ones. Format plugins define on-disk structures, ensuring compatibility and adaptability for different storage scenarios. Examples of formatting options include tails for fragmented , extents for contiguous blocks, and hybrid smart approaches that adapt based on file characteristics. This plugin framework offers significant extensibility benefits, permitting the integration of future enhancements like advanced compression algorithms or custom without requiring kernel modifications—new plugins can be added via updates to the Reiser4 module. It also supports user-defined metadata by treating plugins as modular objects within the , exposing them for programmatic access and customization. Plugins are compiled into the Reiser4 kernel module and user-space tools like libreiser4, with configurations selectable at filesystem creation time using options such as --override for keys or formats. The extensible naming scheme enabled by directory item plugins allows filenames up to 3976 bytes in length, far exceeding typical limits in other systems and accommodating complex or internationalized names.

Compression and Security

Reiser4 provides transparent data compression through dedicated plugins that integrate seamlessly with its extensible architecture. The filesystem supports LZO (Lempel–Ziv–Oberhumer) and zlib compression algorithms, which can be applied at the file or block level to reduce storage requirements without user intervention. These plugins evaluate data compressibility, typically testing whether compression would yield benefits before applying it, with configurable thresholds to balance performance and space savings. Compression is handled within item plugins, where data is compressed on write and decompressed transparently on read, while avoiding unnecessary operations for unmodified compressed blocks to maintain efficiency. Compression ratios in Reiser4 vary significantly depending on the ; for instance, text-heavy or repetitive files achieve higher ratios with zlib, while LZO offers faster for less compressible like binaries. On x86 architectures, Reiser4 supports maximum file sizes of up to 8 TiB, allowing compressed files to scale within these limits while benefiting from the filesystem's efficient packing of small files, which can save approximately 5% in disk space overall. For security, Reiser4 incorporates lists (ACLs) via specialized plugins that enable fine-grained permissions beyond standard attributes. These plugins treat security attributes as hidden files within the , allowing modular enforcement of access rules on a per-file basis. Basic is available through external plugins, such as the cryptcompress plugin, which combines compression with per-file using algorithms like AES, applied transparently before data is stored on disk. However, Reiser4 does not provide native full-disk , relying instead on these loadable plugins for optional protection. This plugin-based approach ensures that security features can be enabled selectively without impacting the core filesystem integrity.

Performance

Benchmark Results

Early benchmarks conducted by Namesys in 2003 demonstrated that Reiser4 was 10 to 15 times faster than for operations on files smaller than 4 KiB, including creation and deletion tasks. These results were obtained on early 2.6 kernels and highlighted Reiser4's efficiency in handling fragmented or numerous small files, though they were based on developer-controlled environments. In mid-term evaluations from 2006, Reiser4 showed mixed results on Linux 2.6 kernels compared to other file systems like XFS. Sequential write performance lagged, with Reiser4 taking 25.40 seconds to create a 1 GB file versus 15.87 seconds for XFS. However, it excelled in random I/O workloads involving small files; for instance, splitting a 10 MB file into 1000-byte segments completed in 2.95 seconds on Reiser4, outperforming XFS's 4.87 seconds. Similar advantages appeared in tests with 1024-byte and 2048-byte files, where Reiser4 times were 2.61 seconds and 1.55 seconds, respectively, against XFS's 4.01 seconds and 1.95 seconds. These benchmarks, run on a standard PC with a 2.4 GHz Athlon XP processor, underscored Reiser4's strengths in metadata-heavy and small-file random access, while noting higher CPU utilization due to plugin overhead. More recent benchmarks in 2013 on 3.10 kernels revealed Reiser4 continuing to outperform and in specific areas. File creation tests showed Reiser4 up to twice as fast as and , particularly for initial compile and metadata-intensive operations on an SSD. Directory listing performance was also superior, with Reiser4 completing large-scale listings more efficiently than the in-kernel alternatives. These results, derived from the on a Lenovo ThinkPad W510 with an Intel Core i7 720QM, confirmed Reiser4's edge in small-file and metadata workloads even on modern hardware, though overall throughput in sequential operations remained competitive but not leading. Factors like plugin architecture were noted to introduce minor overhead in some tests, but without deep analysis. Later benchmarks on 4.17 in 2018 showed Reiser4 lagging behind , , , and in most tests, including FS-Mark file creation and sequential I/O operations, with modern file systems being 2-3 times faster in several workloads. This reflects the lack of ongoing maintenance and optimizations for newer kernel features and hardware.
Test CategoryReiser4 Time (2006)XFS Time (2006)Source
Sequential Write (1 GB file)25.40 s15.87 sLinux Gazette
Random I/O (1000-byte split)2.95 s4.87 sLinux Gazette
Random I/O (1024-byte split)2.61 s4.01 sLinux Gazette
Test CategoryReiser4 Performance (2013)Comparison to ext4/BtrfsSource
File CreationUp to 2x fasterSuperior to bothPhoronix
Directory ListingsEfficient for large setsOutperforms bothPhoronix

Comparisons with Other File Systems

Reiser4 exhibits superior in handling small files compared to , owing to its balanced and optimizations for metadata-intensive operations involving numerous small objects. This advantage stems from Reiser4's design, which minimizes fragmentation and efficiently packs small files, making it particularly suitable for workloads like servers or repositories with many tiny artifacts. However, Reiser4 incurs higher CPU overhead than during intensive operations due to its complex transaction model and plugin processing. While both support journaling for , Reiser4's approach trades some efficiency for atomicity, resulting in greater overhead in high-throughput scenarios compared to 's simpler metadata journaling. In comparisons with , Reiser4 often demonstrates better metadata speed, particularly in tests involving multiple subdirectories and directory traversals, where it outperforms Btrfs by pulling ahead in creation and lookup operations. Unlike Btrfs, which includes built-in support for levels 0, 1, and 10, Reiser4 lacks native RAID integration and relies on external tools like . Reiser4's plugin architecture provides greater flexibility for extending features—such as custom access methods or —compared to Btrfs's subvolume system, which is more oriented toward but less modular for core functionality swaps. Against , Reiser4 offers comparable large-file throughput in sequential read/write benchmarks, with both file systems achieving similar speeds on SSDs for bulk data transfers. Reiser4 excels in fragmented workloads, leveraging its dancing balanced tree to reduce seek times and maintain performance under heavy deletion and insertion patterns. Conversely, is better suited for applications, providing optimized allocation groups and delayed allocation that minimize latency in continuous playback scenarios. Benchmarks from 2013 on Linux 3.10 highlight Reiser4's edge in compile workloads, outperforming due to efficient handling of creation and metadata updates during kernel builds.

History and Development

Origins and Initial Development

Reiser4 was developed by Namesys, a company founded and led by , beginning in 2001 as a successor to the . The project aimed to address limitations in , particularly its journaling mechanism, by designing a complete rewrite that incorporated advanced data structures and extensibility features from the outset. Development received sponsorship from the , which provided funding to enhance secure and efficient storage solutions suitable for environments. Additionally, contributed resources to support desktop integration, aligning Reiser4 with user-friendly distributions. The first alpha snapshot of Reiser4 was released on October 29, 2002, as a set of patches against the then-current , marking the initial public availability for testing and feedback. presented key aspects of the design in technical articles and talks, including discussions on B*-trees and their role in improving balance and caching efficiency, as detailed in publications from late 2002 and early 2003. Early efforts emphasized proofs-of-concept for plugin-based extensibility, allowing modular components for operations like compression and to be developed independently. Version 1.0 of Reiser4 was officially released on August 23, 2004, with patches available for integration into 2.6, enabling users to format and mount file systems with the new implementation. This release built directly on the journaling foundation of but introduced atomic operations and a more flexible architecture to handle diverse workloads.

Challenges and Milestones

Following its initial development, Reiser4 faced significant hurdles in gaining acceptance into the mainline from 2004 to 2008, primarily due to ongoing debates over its architectural choices and integration with the (VFS) layer. Critics, including prominent kernel developers like Christoph Hellwig, highlighted concerns about the filesystem's complexity, unconventional plugin-based design, and code style that deviated from kernel coding standards, leading to protracted code reviews and refusals for merging. These issues were compounded by Hans Reiser's assertive advocacy, which some viewed as combative, further polarizing the community during formal inclusion requests in 2005. The project's momentum was severely disrupted in 2008 when was convicted of second-degree murder and sentenced to 15 years to life in prison, effectively halting Namesys—the company behind Reiser4—and leaving its future uncertain. With Reiser incarcerated and Namesys dissolving, development stalled, and the filesystem risked abandonment as key contributors dispersed. Despite these setbacks, key milestones emerged in the post-conviction era. By 2009, stable patches for 2.6.28 were made available, marking a tentative step toward broader stability. Edward Shishkin, a former Namesys developer, took over maintenance, providing ongoing bug fixes and ensuring compatibility with evolving kernel versions. From 2010 to 2019, Shishkin continued this effort, releasing updated patches for kernels ranging from 3.x to 5.x series, including ports for 3.9 in 2013 and 5.0 in 2019, hosted primarily on with mirrors on . These updates focused on resolving compatibility issues and minor enhancements, sustaining Reiser4 as an out-of-tree option amid its exclusion from mainline.

Reiser5 and Future Directions

In December 2019, Edward Shishkin announced Reiser5 as an evolutionary successor to Reiser4, introducing a new on-disk format designated 5.X.Y to enhance and facilitate potential integration into the mainline. The primary goals included leveraging the (VFS) layer's generic transaction and journaling mechanisms to reduce custom code complexity, thereby improving compatibility with upstream kernel development practices. Additionally, Reiser5 aimed to address scalability limitations of prior versions through the concept of "local volumes," or modular "bricks," enabling parallel I/O operations across multiple storage devices without relying on block-level striping. Key differences from Reiser4 include the adoption of VFS-native transaction handling, which eliminates Reiser4's bespoke journaling implementation and simplifies the overall architecture by aligning more closely with kernel standards. The new format supports reading and mounting existing Reiser4 partitions (version 4.0.X) for , while introducing asymmetric volume plugins and distribution plugins to manage data across local volumes for better handling of large-scale storage. This volume-based approach is designed to improve performance on high-capacity systems by allowing independent meta-data bricks per volume, though initial implementations limited support to a single meta-data brick. As of 2025, Reiser5 remains in an early prototype stage with no integration into the mainline, and development has effectively stalled since around 2022. The associated repository for Reiser4 and Reiser5 patches, maintained by Shishkin, shows no commits since approximately 2022, indicating a lack of ongoing activity. Similarly, Reiser4 kernel patches have been unmaintained since 2022, with the last update for 5.16 released in April 2022; user inquiries in subsequent years going unanswered regarding updates for newer kernel versions. As of late 2024, the project remains inactive and appears effectively abandoned. Without significant sponsorship or corporate backing—similar to the challenges faced by Reiser4—prospects for Reiser5 achieving mainline status or broader adoption appear dim, though its lightweight design could hold niche potential in embedded systems where custom kernel patching is feasible.

Integration and Adoption

Linux Kernel Status

Reiser4 patches were first submitted for consideration in the mainline Linux kernel in 2004, with significant development and resubmission efforts continuing through 2009. These submissions faced substantial scrutiny from kernel maintainers, including Theodore Ts'o, who rejected inclusion primarily due to concerns over code quality, such as violations of virtual file system (VFS) layering principles and overly complex internal interfaces that bypassed established kernel abstractions. Ts'o and other reviewers, including Christoph Hellwig and Al Viro, emphasized that the codebase required extensive refactoring to align with kernel standards, and the lack of rigorous testing and documentation further hindered approval. Despite iterative improvements, no version achieved consensus for merging during this period. One early barrier was licensing incompatibility, as initial Reiser4 code included non-GPL elements that conflicted with the kernel's requirements; this was resolved by 2005 through relicensing efforts to ensure full GPL compliance. However, persistent issues revolved around the file system's architectural complexity, which introduced plugin-based extensibility that maintainers viewed as unstable and difficult to audit, alongside inadequate handling of error conditions and performance regressions in certain workloads. The arrest and 2008 conviction of primary developer for murder led to the dissolution of Namesys, the company behind Reiser4, resulting in a critical lack of dedicated maintenance thereafter; while volunteer efforts, such as those by Edward Shishkin, have sustained the project minimally, no committed maintainer has emerged to address kernel integration requirements. As of November 2025, Reiser4 remains excluded from the mainline , with no active proposals for inclusion and its development effectively stalled, with the primary repository showing no updates since before 2025. It is available only as an out-of-tree module, with patches maintained on repositories like for kernels up to version 5.15 through custom builds. Historical inclusion in Andrew Morton's -mm development kernels has ceased, though some patchsets like older kernel variants supported it; current distributions rarely provide prebuilt modules, requiring users to compile from source for compatibility. This status contrasts with the removal of its predecessor, , from the mainline in 6.13 (released January 2025), a decision driven by similar legacy maintenance burdens and signaling broader kernel cleanup of unmaintained file systems.

Usage in Distributions and Alternatives

Reiser4's adoption in distributions remains limited due to its exclusion from the mainline kernel, requiring users to rely on out-of-tree patches or custom builds for support. Historically, provided packages enabling Reiser4 usage, allowing installations on Reiser4 partitions without reformatting. In Gentoo, support is possible through custom kernel configurations, though developers discourage its use owing to stability concerns. offers experimental access via third-party kernel modules, with user-space tools like reiser4progs available in repositories for basic management. The is suited for metadata-intensive applications, such as mail servers handling numerous small files and frequent directory operations, where its plugin-based and efficient metadata management provide advantages in for such workloads. However, its practical usage has declined sharply due to the absence of upstream and integration challenges. For users seeking alternatives, migration to is recommended for its robust journaling and broad compatibility, while offers advanced capabilities like snapshots and compression for modern needs. The reiser4progs package facilitates creation, checking, and limited conversion tasks during such migrations. As of 2025, Reiser4 maintains only minimal active users, confined mostly to legacy or experimental setups, with distributions issuing warnings about its obsolescence akin to the full removal of its predecessor from the in Linux 6.13 (released January 2025).

References

  1. https://github.com/edward6/reiser4
  2. https://lwn.net/Articles/41652/
  3. https://arunraghavan.net/downloads/talks/reiser4.8sem.pdf
  4. https://sourceforge.net/projects/reiser4/
  5. https://lwn.net/Articles/193663/
  6. https://docs.kernel.org/process/3.Early-stage.html
  7. https://www.phoronix.com/news/Reiser4-Linux-5.3-Patch
  8. https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-5.x/
  9. https://sourceforge.net/projects/metztli-reiser4/
  10. https://www.linuxjournal.com/article/6267
  11. https://www.linuxjournal.com/article/6569
  12. https://lkml.org/lkml/2006/7/21/109
  13. https://dl.acm.org/doi/fullHtml/10.5555/770650.770654
  14. https://lwn.net/2001/1108/a/reiser4-transaction.php3
  15. https://lwn.net/Articles/100148/
  16. https://metztli.blog/amatl/reiser-nahui/reiser4-design
  17. https://os.itec.kit.edu/downloads/sysarch25-file3.pdf
  18. https://manpages.debian.org/testing/reiser4progs/mkfs.reiser4.8.en.html
  19. https://forums.gentoo.org/viewtopic-t-707465.html
  20. https://en-academic.com/dic.nsf/enwiki/233772
  21. https://lwn.net/Articles/41653/
  22. https://linuxgazette.net/122/piszcz.html
  23. https://www.phoronix.com/review/linux_310_10fs
  24. https://www.phoronix.com/review/linux_310_reiser4
  25. https://www.phoronix.com/review/reiser4-linux-417
  26. https://www.phoronix.com/review/reiser4_benchmarks
  27. https://www.linux-magazine.com/content/download/63001/486756/version/1/file/File_Systems.pdf
  28. https://download.boulder.ibm.com/ibmdl/pub/software/dw/linux/l-journaling-filesystems/l-journaling-filesystems-pdf.pdf
  29. https://www.phoronix.com/review/reiser4_linux35/2
  30. https://www.osnews.com/story/5538/lindowscom-to-use-reiserfs-4/
  31. https://lwn.net/Articles/14002/
  32. https://hardware.slashdot.org/story/04/08/24/0058234/reiser4-filesystem-released
  33. https://www.osnews.com/story/8107/reiser4-is-released/
  34. https://www.linux.com/news/reiser4-and-politics-kernel/
  35. https://groups.google.com/g/fa.linux.kernel/c/EFmMT8oWBQ4
  36. https://lwn.net/Articles/280228/
  37. https://www.phoronix.com/news/MTAwMjA
  38. https://serverfault.com/questions/11440/to-what-extent-has-reiserfss-popularity-been-lessened-by-hans-reiser
  39. https://www.phoronix.com/news/Reiser4-Linux-5.0-Patch
  40. https://lkml.org/lkml/2019/12/31/146
  41. https://www.phoronix.com/news/Reiser5-Development
  42. https://www.phoronix.com/news/Reiser5-Five-Years-Old
  43. https://github.com/edward6/reiser4/issues/15
  44. https://sourceforge.net/projects/reiser4/files/v5-unstable/kernel/reiser4-for-5.16.patch.gz
  45. https://lkml.org/lkml/2005/9/16/121
  46. https://yarchive.net/comp/linux/reiser4.html
  47. https://lwn.net/Articles/151204/
  48. https://kernelnewbies.org/WhyReiser4IsNotIn
  49. https://www.phoronix.com/news/Hans-Reiser-2024
  50. https://www.phoronix.com/search/Reiser4
  51. https://www.phoronix.com/news/ReiserFS-Deleted-Linux-6.13
  52. https://www.osnews.com/story/12487/reiser4-for-slackware-linux/
  53. https://forums.gentoo.org/viewtopic-t-385836.html
  54. https://wiki.ubuntu.com/Reiser4
  55. https://packages.debian.org/bullseye/reiser4progs
Add your contribution
Related Hubs
User Avatar
No comments yet.