Both are imho linked to "offline desktop use cases are not important anymore". Both companies saw their future gains elsewhere, in internet-related functions and what became known as "cloud". No need to have a fancy, featurefull and expensive filesystem when it is only to be used as a cache for remote cloud stuff.
Linux or FreeBSD developers are free to adopt ZFS as their primary file systems. But it appears that practical benefits are not really evident to most users.
ZFS is a first class citizen in FreeBSD and has been for at least a decade(probably longer). Not at all like in most Linux distros.
Linux or FreeBSD developers are free to adopt ZFS as their primary file systems. But it appears that practical benefits are not really evident to most users.
The ZFS license makes it impossible to include in upstream Linux kernel, which makes it much less usable as primary filesystem.
Linux’s signed off policy makes that impossible. Linus Torvalds would need Larry Elison’s signed off before even considering it. Linus told me this by email around 2013 (if I recall correctly) when I emailed him to discuss user requests for upstream inclusion. He had no concerns about the license being different at the time.
While its deduplication feature clearly demands more memory, my understanding is that the ZFS ARC is treated by the kernel as a driver with a massive, persistent memory allocation that cannot be swapped out ("wired" pages). Unlike the regular file system cache, ARC's eviction is not directly managed by the kernel. Instead, ZFS itself is responsible for deciding when and how to shrink the ARC. This can lead to problem…
Solaris achieved some kind of integration between the ARC and the VM subsystem as part of the VM2 project. I don't know any more details than that.
I assume that the VM2 project achieved something similar to the ABD changes that were done in OpenZFS. ABD replaced the use of SLAB buffers for ARC with lists of pages. The issue with SLAB buffers is that absurd amounts of work could be done to free memory, and a single long lived SLAB object would prevent any of it from mattering. Long lived slab objects caused excessive reclaim, slowed down the process of freeing enough memory to satisfy system needs and in some cases, prevented enough memory from being freed to satisfy system needs entirely. Switching to linked lists of pages fixed that since the memory being freed from ARC upon request would immediately become free rather than be deferred to when all of the objects in the SLAB had been freed.
Kind of odd that the blog states that "The architect for ZFS at Apple had left" and links to the LinkedIn profile of someone who doesn't have any Apple work experience listed on their resume. I assume the author linked to the wrong profile?
Ex-Apple File System engineer here who shared an office with the other ZFS lead at the time. Can confirm they link to the wrong profile for Don Brady. This is the correct person: https://github.com/don-brady Also can confirm Don is one of the kindest, nicest principal engineer level people I’ve worked with in my career. Always had time to mentor and assist.
Given your expertise, any chance you can comment on the risk of data corruption on APFS given that it only checksums metadata?
Besides the licensing issue, I wonder if optimizing ZFS for low latency + low RAM + low power on iPhone was an uphill battle or if it’s easy. My experiencing running ZFS years ago was poor latency and large RAM use with my NAS, but that hardware and drive configuration was optimized for low $ per gb stored and used parity stuff.
Apple wanted one operating system that ran on everything from a Mac Pro to an Apple Watch and there’s no way ZFS could have done that.
ZFS would be quite comfortable with the 512MB of RAM on an Apple Watch:
Yeah I think if it hadn’t been for the combination of Oracle and CDDL, Red Hat would have been more interested in for Linux. As it was they basically went with XFS and volume management. Fedora did eventually go with btrfs but dints know if there are are any plans for copy-on-write FS for RHEL at any point.
Fedora Server uses XFS on LVM by default & you can do CoW with any modern filesystem on top of an LVM thin pool. And there is also the Stratis project Red Hat is involved in: https://stratis-storage.github.io/
TIL Stratis is still alive. I thought it basically went on life support after the lead dev left Red Hat.
Linux or FreeBSD developers are free to adopt ZFS as their primary file systems. But it appears that practical benefits are not really evident to most users.
Lots of ZFS users are enthusiasts who heard about that one magic thing that does it all in one tidy box. Whereas usually you would have to known all the minutiae of LVM/mdadm/cryptsetup/nbd and mkfs.whatever to get to the same point. So while ZFS is the nicer-dicer of volume management and filesystems, the latter is your whole chef's knife set. And while you can dice with both, the user groups are not the same. And e…
Ubuntu's ZFS-on-root with zsys auto snapshots have been working excellently on my server for 5 years. It automatically takes snapshots on every update and adds entries to grub so rolling back to the last good state is just a reboot away.
True and I understand the caution considering Oracle is involved which are an awful company to do deal with (and their takeover of Sun was a disaster). But really, this is a concern for distros. Not for end users. Yet many of the Linux users I speak to are somehow worried about this. Most can't even describe the provisions of the GPL so I don't really know what that's about. Just something they picked up, I guess.
Licensing concerns that prevent distros from using ZFS will sooner or later also have adverse effects on end users. Actually those effects are already there: The constant need to adapt a large patchset to the current kernel, meaning updates are a hassle. The lack of packaging in distributions, meaning updates are a hassle. And the lack of integration and related tooling, meaning many features can not be used (like a/…
Unlike other out of tree filesystems such as Reiser4, the ZFS driver does not patch the kernel sources.
As a desktop user, I am content with APFS. The only feature from ZFS that I would like, is the corruption detection. I honestly don't know how robust the image and video formats are to bit corruption. On the one hand, potentially, "very" robust. But on the other, I would think that there are some very special bits that if toggled can potentially "ruin" the entire file. But I don't know. However, I can say, every time…
> Just trying to set it up on a single USB drive That's the fault of macOS, I also experienced 100% CPU and load off the charts and it was kernel_task jammed up by USB. Once I used a Thunderbolt enclosure it started to be sane. This experience was the same across multiple non-Apple filesystems as I was trying a bunch to see which one was the best at cross-os compatibility Also, separately, ZFS says "don't run ZFS on…
Yeah they do say that but anecdotally my Plex server has been ZFS over USB 3 since 2020 with zero problems (using Ubuntu 20.04)
Anyway only bringing it up to reinforce that it is probably a macOS problem.