A lot of this goes over my head as someone who isn't familiar with filesystem internals, but I appreciate the effort and the homage to a great tool.
A lot of this goes over my head as someone who isn't familiar with filesystem internals, but I appreciate the effort and the homage to a great tool.
I think maybe that's the one feature that's iffy? Theoretically great but bad history of bugs. (Unfortunately)
Totally worth it for NAS. I think there are more systems that utilize its advanced dataset features in the BSD world.
The licensing issues don’t help. Consider that most Linux machines are in commercial settings (Google runs more of them than all individuals combined) and they don’t need Oracle on their backs.
There is nothing complicated about having zfs be your filesystem. You can use its extra features like snapshots, send/receive, etc, but only if you wanted to. Otherwise it's just a filesystem, there is nothing to use as such, so nothing complicated.
> and isn’t necessary for most workloads.
Not sure what that means. What workload wouldn't benefit from a reliable filesystem?
Linux is the most common platform and many Linux distributions have an issue with license compatibility (or perceived one), which hinders adoption.
In the end, I think it's momentum and licensing. AFAICT btrfs only exists because ZFS can't be shipped in Linux kernel. Defaults are insanely powerful, and ext4/xfs is good enough for a lot of use cases. If ZFS were BSD or GPL licensed, I think every Linux distro would ship with it as an option, if not a default.
The issue is, the GPL wants to spread to everything it touches (including the CDDL-licensed ZFS files), which would make the ZFS files subject to both the GPL and the CDDL. But the CDDL and the GPL are incompatible, which is why Linux can't include ZFS whereas more permissively licensed projects like the BSDs can.
So it's an unfortunate situation, but ZFS' license is not "bad". It's just the GPL and the CDDL are incompatible.