RedoxFS is the default filesystem of Redox OS, inspired by ZFS

Original Article ↗ Hacker News Discussion ↗

RedoxFS, a Rust-based filesystem inspired by ZFS, is being developed as the default storage layer for the experimental microkernel-based Redox OS, aiming to bring copy-on-write, checksumming, encryption and planned snapshot support into a clean, MIT-licensed design. Commenters contrast it with ZFS and Btrfs, noting licensing conflicts, ZFS’s “monolithic” integration challenges, and Btrfs’s reliability history as reasons to build something new rather than port existing code. While many see writing a new filesystem as risky and long-haul work, others argue Redox’s role as a research platform justifies ambitious experiments that could surface better designs for safety, correctness and capability-based security.

Choice of filesystem & licensing

  • Multiple comments ask why Redox didn’t just adopt btrfs, ZFS, or HAMMER2.
  • Licensing is a major theme:
    • Redox is MIT-licensed; btrfs is GPL (seen as “viral” and incompatible with their goals).
    • ZFS is CDDL; combining CDDL and MIT is seen as feasible, unlike CDDL+GPL.
  • Some suggest HAMMER2 or bcachefs as better fits (copyfree license, microkernel-friendly), but no one reports an active port.

ZFS and microkernel design

  • Redox previously had a read‑only ZFS driver but abandoned it due to ZFS’s “monolithic nature” clashing with their microkernel approach.
  • Discussion suggests ZFS tightly integrates volume management, RAID, caching (ARC), and filesystem, making it hard to decompose into separate services with isolated memory spaces.
  • Others argue ZFS is internally modular but presents a very integrated, invasive interface (own cache, pool import/export model, many tunables), which can be awkward for “general purpose” OS use.

btrfs vs ZFS reliability experiences

  • Several anecdotes describe severe btrfs failures, especially with flaky drives and RAID1, where recovery tools couldn’t restore a canonical, usable filesystem.
  • One commenter defends btrfs, noting its flexible metadata placement complicates repair but enables powerful features; Fedora’s long-standing default use is cited as evidence of acceptable reliability.
  • Some users report switching to ZFS afterward and finding it more “rock solid.”

RedoxFS features and technical limits

  • RedoxFS is ZFS-inspired, supports checksums and optional full-disk encryption, with plans or recent additions for snapshots and transparent compression.
  • Encryption is said to cover metadata as well as data.
  • Noted limits: 32-bit inode count (~4B objects per ~193 TiB) and a ~193 TiB max file/directory size; some see this as practically fine, others already have multi‑TB files and are concerned.

Redox OS maturity & usability

  • Redox is praised as an advanced Linux alternative but acknowledged as not production-ready.
  • Major gaps include lack of GPU support; only a UEFI framebuffer is currently available.
  • Intended primarily for experimentation; running in VMs is common, though some would prefer real hardware.

New filesystem risk vs experimentation & Rust

  • Some compare writing a new FS to “rolling your own crypto” and note that robust filesystems historically took many years to mature.
  • Others counter that Redox’s goal is exploration, not immediate wide adoption, and Rust’s safety and ergonomics may help avoid classes of bugs common in C-based filesystems.
  • RedoxFS is seen by some as part of a broader effort to incubate low‑level Rust infrastructure (e.g., capability-based descriptors).

Miscellaneous

  • Discussion branches into comparisons with other OS projects (Genode, Fuchsia) and licensing philosophies (MIT vs copyleft).
  • Minor notes include a doc typo in an example fusermount3 command and a Spanish pun on Redox’s pkgar tool name.