ReiserFS
ReiserFS is a general-purpose file system, designed and implemented by a team at Namesys, led by Hans Reiser.
As of Linux 2.4.1, ReiserFS became the first journal filesystem to be included in the standard kernel. It was also the default file system in several distributions, such as SuSE (until 2006, when it was replaced by ext3), Knoppix and other currently discontinued distributions such as Xandros, Yoper, Linspire, Kurumin Linux, FTOSX, Libranet.
With the exception of security updates and critical patches, Namesys has ceased development of ReiserFS (also called reiser3) to focus on Reiser4, the successor to this file system.
ReiserFS is currently supported by Linux, although its removal from the Linux kernel has been under discussion since early 2022 due to lack of support, maintenance, and inherent filesystem glitches, such as the Year 2038 issue. Linux kernel system removal is currently set for 2025.
Features
ReiserFS offers features that have rarely been seen in other file systems:
- Journaling. This is the improvement to which more advertising has been given, as it prevents the risk of corruption of the file system.
- Distribution with mounted and disassembled file system. We can increase the size of the file system while mounting and disassembling it (online and offline). To reduce it, it is only allowed to be offline (disassembled). Namesys provides the tools for these operations, and even we can use them under a logical volume manager such as LVM or EVMS.
- Tail packing, a scheme to reduce internal fragmentation.
Performance
Compared to ext2 and ext3 when using files under 4k, ReiserFS is typically faster by a factor of 10–15. This provides a high gain in news, such as Usenet, caches for HTTP services, mail agents and other applications where the access time to small files must be as fast as possible.
Disadvantages
- Users who use as ext2 file system should format their disks, although not those using ext3.
- ReiserFS in kernel versions prior to 2.4.10 is considered unstable and not recommended for use, especially in conjunction with NFS
- Some file operations (e.g. unlink(2)) are not synchronous under ReiserFS, which can cause strange behaviors in applications strongly based on file locks.
- There is no known way to defrag a ReiserFS file system, apart from a full dump and its restoration.
- Early implementations of ReiserFS (previous to that included in kernel 2.6.2) were susceptible to write problems out of order, which caused files to be written during a system crash, to gain a peak of extra trash bytes on the next mounted file system. The current implementation of journaling is correct in this regard, keeping the journaling orderly, of the style of ext3.
Design
ReiserFS stores metadata about files, directory entries, and inode lists in a single B+ tree whose primary key is a unique identifier. The disk blocks assigned to the tree nodes are the "internal formatted blocks" and the leaf blocks are the "formatted leaf blocks". All the remaining blocks are the "unformatted blocks", which contain the data of the files. Directories with many entries, either direct or indirect, that do not fit on a single node are partitioned with the neighboring node to the right. The allocation of blocks is carried out by means of a bitmap of free space stored in fixed locations.
In contrast, ext2 and other filesystems use a fixed formula to calculate inode locations, thus limiting the number of files they can store. Others also store directories as a simple list of entries, causing searches and modifications to be temporarily linear operations and degrading the performance of directories with many files. The B+ tree in ReiserFS avoids these problems.
Versions
There are mainly two versions of this file system: 3 and 4. The characteristics are the following:
3.5 | 3.6 | |
---|---|---|
Maximum number of files | 2 32 - 3 = 4 Gi - 3 | 232 - 3 = 4 Gi - 3 |
Maximum number of files that can contain a directory | 518701895, but in practice this value is limited by a hash function. The hash r5 allows between 1 and 200000 file names without collisions. | 232 - 4 = 4 Gi - 4, but in practice this value is limited by a hash function. The hash r5 allows between 1 and 200000 file names without collisions. |
Maximum size of a file | 231 - 1 = 2 Gi - 1 | 260 - some bytes = 1 Ei, but the page cache limits it to 8 Ti in 32-bit architectures. |
Maximum number of links to a file | 216 = 64 Ki | 232 = 4 Gi |
Maximum file system size | 232 (4K) blocks = 16 Ti | 232 (4K) blocks = 16 Ti |
Contenido relacionado
Spacewar!
Window manager
Cyber coffee