> Redox had a read-only ZFS driver but it was abandoned because of the monolithic nature of ZFS that created problems with the Redox microkernel design.
Curious about the details behind those compatibility problems.
Zfs relies on Solaris (Unix) kernel primitives IIRC ... I remember hearing that to get zfs to work with an is you basically have to implement a good portion of the Solaris kernel interface as shims
Yeah I've always written this off as a fun side project for a group of people but after seeing consistent updates and improvements over the last several years I've been so impressed by how far this project has been going.
I can only speculate, but maybe they're referring to the same thing Andrew Morton meant when he described ZFS as a rampant layering violation.
ie ZFS isn't just a file system. It's a volume manager, raid and file system rolled into one holistic system vs for example LVM + MD + ext4.
And (again I'm only speculating) in their micro kernel design want to have individual components running separately to layer together a complete solution.
I don’t think it’s microkernels in general but their microkernel design which wants as much as possible in userspace. They want each component to have its own memory space. ZFS blurs the layers between filesystem and the volume management. This kinda bothers layers of abstraction model folks. And I assume combined with their posix like model it just sorta clashes with what they want to do. Not impossible to integrate, but they want something a little different.
If I had to guess, it is because ZFS likes to insert itself into things beyond just being a filesystem. It is one of the reasons ZFS notoriously works poorly with database engines, which have a tendency to bypass or ignore the filesystem (for good reason). It is a design choice on the part of ZFS.
Innovation is wonderful, but it’s hard to believe this has enough users to flush out the challenging bugs. Maybe if it had some kind of correctness proof, but it just seems like there are way too many subtle bugs in file systems in general for me to try a new FS.
I'm not a filesystem person, but this sets off similar red flags to rolling your own encryption.
Isn't writing a robust file system something that routinely takes on the order of decades? E.g. reiserfs, bcachefs, btrfs.
Not to rain on anyone's parade. The project looks cool. But if you're writing an OS, embarking on a custom ZFS-inspired file system seems like the ultimate yak shaving expedition.
Several FS problems that are difficult to fix with incremental changes to legacy code bases:
* inotify implementation is insufficiently atomic, so event subscribers can fail to receive notifications under certain conditions.
* License/patent encumbrance prevents modern operating systems from implementing/distributing a common next-gen FS.
* ZFS has native encryption in theory but it was bolted on later and has numerous buggy interactions the powerful zfs send/recv.
* ZFS native encryption is architecturally incapable of protecting metadata like filenames.
There is lots of room for innovation, and with modern tools it shouldn't take decades to build a production-ready driver for any one ISA (presumable x86_64.) If this project wants to pilot a superior option, I'm all for it!
I hope someone can bring this issue to redox-os project about its package management command "pkgar". Reading it aloud in spanish sounds as "pa cagar". "pa" is a very common contramption of "para" so we have "para cagar" which translated back is "to shit".
Sorry for commenting this here, Redox is using a private gitlab instance I have no access to.
I've occasionally pondered, how feasible would it be to write a APFS implementation just from the specs[0] alone. Is it harder or easier to create the implementation when you have a provided layout and mechanism how it works. Would it be easy to keep compatibility, and would it be a dead-end design for extensions that you'd like?
This would be a significant problem with my use case in the very near future. I already have double-digit-TB files, and that doesn't look like much margin on top of that.
I've been dogfooding bcachefs for a few months, aside from a nixos kernel regression, and LKML drama :-(, it's been good (anecdote +1) I was early on the reiser4 bandwagon back on gentoo, a glutton for data loss is what I am...
I run nixos unstable, at some point in the last few weeks the kernel supplied with
* boot.supportedFilesystems = [ "bcachefs" ];
in my config, went from version 6.16.0 to 6.12.45 and I had very long boot times (30 minutes+) with a lot of messages. My solution was to switch to the latest kernel
* boot.kernelPackages = pkgs.linuxPackages_latest;
Which bumped me back up to kernel 6.16.8 and smooth sailing.
"[..] In this project we will replace Redox's internal file descriptor representation with capability descriptors, optimized for both security and performance. This will provide a foundation for capability-based security on Redox, and possibly capability extensions from other UNIX-like systems, while also supporting POSIX-style file descriptors for application compatibility".
36 comments
[ 5.1 ms ] story [ 65.7 ms ] threadCurious about the details behind those compatibility problems.
Anyone have an idea what this actually means and what problems they were having in practice?
ie ZFS isn't just a file system. It's a volume manager, raid and file system rolled into one holistic system vs for example LVM + MD + ext4.
And (again I'm only speculating) in their micro kernel design want to have individual components running separately to layer together a complete solution.
32bit inodes? why?
Other systems had to go through pains to migrate to 64bit. Why not skip that?
Isn't writing a robust file system something that routinely takes on the order of decades? E.g. reiserfs, bcachefs, btrfs.
Not to rain on anyone's parade. The project looks cool. But if you're writing an OS, embarking on a custom ZFS-inspired file system seems like the ultimate yak shaving expedition.
Rust people love doing that, let them. Let them introduce logic bugs across the codebase. Sounds fun.
[1] https://en.m.wikipedia.org/wiki/HAMMER_(file_system)
* inotify implementation is insufficiently atomic, so event subscribers can fail to receive notifications under certain conditions.
* License/patent encumbrance prevents modern operating systems from implementing/distributing a common next-gen FS.
* ZFS has native encryption in theory but it was bolted on later and has numerous buggy interactions the powerful zfs send/recv.
* ZFS native encryption is architecturally incapable of protecting metadata like filenames.
There is lots of room for innovation, and with modern tools it shouldn't take decades to build a production-ready driver for any one ISA (presumable x86_64.) If this project wants to pilot a superior option, I'm all for it!
* RedoxFS is MIT licensed
* RedoxFS supports all features with or without full disk encryption
* RedoxFS encryption includes all metadata
Sorry for commenting this here, Redox is using a private gitlab instance I have no access to.
at the end of the page should read
`fusermount3 -u ./redox-img`
[0] https://developer.apple.com/support/downloads/Apple-File-Sys...
This would be a significant problem with my use case in the very near future. I already have double-digit-TB files, and that doesn't look like much margin on top of that.
I'm excited for RedoxFS time for to have a play!
Unless you meant rawdogging or another similar sounding word to dogfooding?
NixOS and Arch are the two distros that are making the DKMS transition the smoothest.
Source: https://nlnet.nl/project/Capability-based-RedoxOS/
"[..] In this project we will replace Redox's internal file descriptor representation with capability descriptors, optimized for both security and performance. This will provide a foundation for capability-based security on Redox, and possibly capability extensions from other UNIX-like systems, while also supporting POSIX-style file descriptors for application compatibility".