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

Original Article ↗ Hacker News Discussion ↗

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.