Skip to content
EntityQ2293002· pop 11· linked from 166 articles

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. , the Reiser4 patch set is still being maintained, but according to Phoronix, it is unlikely to be merged into mainline Linux without corporate backing.

Key facts

Filesystem.name
Reiser4
Filesystem.full_name
Reiser4
Filesystem.developer
Edward Shishkin and others
Filesystem.introduction_os
Linux
Filesystem.OS
Linux
Filesystem.partition_id
Apple_UNIX_SVR2 (Apple Partition Map) 0x83 (MBR) Basic data partition (GPT)
Filesystem.directory_struct
Dancing B*-tree
Filesystem.max_filename_size
3976 bytes
Filesystem.max_file_size
8 TiB on x86
Filesystem.filename_character_set
All bytes except NUL and '/'
Filesystem.dates_recorded
modification (mtime), metadata change (ctime), access (atime)
Filesystem.date_range
64-bit timestamps
Filesystem.forks_streams
No
Filesystem.file_system_permissions
Unix permissions
Filesystem.compression
Yes
Filesystem.encryption
No
Filesystem.single_instance_storage
No
Filesystem.website
reiser4.wiki.kernel.org

via Wikipedia infobox

Wikidata facts

Show 1 more fact
inception
2004-00-00
Sources (2)

via Wikidata · CC0

~6 min read

Article

7 sections
Contents
  • Features
  • Performance
  • Integration with Linux
  • History of Reiser4
  • See also
  • References
  • External links

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. , the Reiser4 patch set is still being maintained, but according to Phoronix, it is unlikely to be merged into mainline Linux without corporate backing.

== Features == 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 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 Mirrors and failover Precise discard support with delayed issuing of discard requests for SSD devices

Connections

Categories