Reiser4
Sign in to saveReiser4 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 sectionsContents
- 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