| Developer(s) | Namesys |
|---|---|
| Full name | ReiserFS |
| Introduced | 2001; 24 years ago (2001) withLinux 2.4.1 |
| Partition IDs |
|
| Structures | |
| Directory contents | B+ tree |
| File allocation | Bitmap[1] |
| Limits | |
| Max volume size | 16TiB[2] |
| Max file size | 1EiB (8TiB on 32 bit systems)[2] |
| Maxno. of files | 232−3 (~4 billion)[2] |
| Max filename length | 4032 bytes, limited to 255 by Linux VFS |
| Allowed filename characters | All bytes exceptNUL and'/' |
| Features | |
| Dates recorded | Modification (mtime), metadata change (ctime), access (atime) |
| Date range | December 14, 1901 – January 18, 2038 (32-bit Unix time) |
| Date resolution | 1 s |
| Forks | Extended attributes |
| File system permissions | Unix permissions,ACLs and arbitrary security attributes |
| Transparent compression | No |
| Transparent encryption | No |
| Other | |
| Supported operating systems | Linux,ReactOS |
ReiserFS is a general-purpose,journaling file system initially designed and implemented by a team atNamesys led byHans Reiser and licensed underGPLv2. Introduced in version 2.4.1 of theLinux kernel, it was the first journaling file system to be included in the standard kernel. ReiserFS was the default file system inNovell's SUSE Linux Enterprise until Novell decided to move toext3 for future releases on October 12, 2006.[3]
ReiserFS version 3.6, now occasionally referred to as Reiser3, introduced a new on-disk format allowing larger filesizes. Namesys considered ReiserFS stable and feature-complete and ceased development on it to concentrate on its successor,Reiser4, though it continued to release security updates and critical bug fixes. Namesys went out of business in 2008 after Reiser's conviction for murder. The product is now maintained as open source by volunteers.[4] The reiserfsprogs 3.6.27 were released on 25 July 2017.[5]
As ofLinux 6.12, ReiserFS is supported on Linux without quota support. Due to technical issues inherent to the file system and lack of maintenance, Linux community had been discussing removal of ReiserFS from mainline since at least early 2022. ReiserFS was removed from the Linux kernel in version 6.13.[6][7]
At the time of its introduction, ReiserFS offered features that had not been available in existing Linux file systems. These includetail packing—a scheme to reduceinternal fragmentation at cost of performance. Reiser4 may have improved this by packing tails where it does not negatively affect performance.[8]
ReiserFS stores file metadata ("stat items"),directory entries ("directory items"),inode block lists ("indirect items"), and tails offiles ("direct items") in a single, combinedB+ 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 byfree space bitmaps in fixed locations.
By contrast,ext2 and other BerkeleyFFS-like file systems of that time simply used a fixed formula for computing inode locations, hence limiting the number of files they may contain.[9] Most such file systems also store directories as simple lists of entries, which makes directory lookups and updateslinear time operations and degrades performance on very large directories. The singleB+ tree design in ReiserFS avoids both of these problems due to better scalability properties.
Compared withext2 andext3 in version 2.4 of the Linux kernel, when dealing with files under 4 KiB and with tail packing enabled, ReiserFS may be faster.[10]
Before Linux 2.6.33,[11] ReiserFS heavily used thebig kernel lock (BKL)—a global kernel-wide lock—which does not scale well for systems with multiple cores,[12] 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),[13][14] until switching toext3 inSUSE Linux Enterprise 10.2 andopenSUSE 11, announced in 2006.[15][16]
Jeff Mahoney of SUSE wrote a post on 14 September 2006 proposing to move from ReiserFS toext3 for the default installation file system.[12] The reasons he mentioned included scalability, "performance problems withextended attributes andACLs", "a small and shrinking development community", and that "Reiser4 is not an incremental update and requires a reformat, which is unreasonable for most people."[12] On October 4 he wrote a response comment on a blog in order to clear up some issues.[17] He wrote that his proposal for the switch was unrelated to Hans Reiser being under trial for murder.[18][failed verification] 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."[17]
ReiserFS has been discussed for removal from the Linux kernel since early 2022 due to a lack of maintenance upstream, and technical issues inherent to the filesystem, such as suffering from theyear 2038 problem;[19][20][21] it was deprecated in Linux 5.18,[22] and marked as obsolete in Linux 6.6,[23] with complete removal planned for Linux 6.13.[24][25][26] ReiserFS was removed from mainline during Linux 6.13 development cycle.[7][6]
Some directory operations (includingunlink(2)) are notsynchronous on ReiserFS, which can result in data corruption with applications relying heavily on file-based locks (such asmail transfer agents likeqmail[27] andPostfix[28]) if the machine halts before it has synchronized the disk.[29]
There are no programs to specificallydefragment 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.[30] Fragmentation is still an issue withSSD regardless of file system.[31]
ReiserFS 3'sfsck is capable of rebuilding the whole tree as part of the rescue in case of its total corruption. This action has to be explicitly initiated by administrator and is not part of normal operation. Predictably, the process is destructive and may further corrupt existing files or introduce new entries with unexpected contents, which has been criticized as a less than optimal method.[32]
ReiserFS v3 images should not be stored on a ReiserFS v3partition (e.g. backups ordisk images for emulators) without transforming them (e.g., by compressing or encrypting) in order to avoid confusing the rebuild. Reformatting an existing ReiserFS v3 partition can also leave behind data that could confuse the rebuild operation and make files from the old system reappear. This also allows malicious users to intentionally store files that will confuse the rebuilder. As the metadata is always in a consistent state after a file system check,corruption here means that contents of files are merged in unexpected ways with the contained file system's metadata. This is similar to the FSID problem inbtrfs. The ReiserFS successor, Reiser4, fixes this problem.
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 withNFS.[33]
Early implementations of ReiserFS (prior to that in Linux 2.6.2) were also susceptible to out-of-order write hazards. But the current journaling implementation in ReiserFS is now on par with that ofext3's "ordered" journaling level.[citation needed]
{{cite web}}: CS1 maint: numeric names: authors list (link)