The death of ZFS in macOS was a huge shift in the industry. This has to be seen in the context of microsoft killed their largely ambitious WinFS which felt like the death of desktop innovation in combination.
APFS? That still happened.
ZFS: Apple's new filesystem that wasn't (2016)
111–120 of 209 posts
Re: ZFS: Apple's new filesystem that wasn't (2016)
#112ZFS sort of moved inside the NVMe controller - it also checksums and scrubs things all the time, you just don't see it. This does not, however, support multi-device redundant storage, but that is not a concern for Apple - the vast majority of their devices have only one storage device.
Re: ZFS: Apple's new filesystem that wasn't (2016)
#113Earlier quoted context omitted.
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 on FreeBSD is quite nice. System tools like freebsd-update integrate well. UFS continues to work as well, and may be more appropriate for some use cases where ZFS isn't a good fit, copy on write is sometimes very expensive.
Afaik, the FreeBSD position is both ZFS and UFS are fully supported and neither is secondary to the other; the installer asks what you want from ZFS, UFS, Manual (with a menu based tool), or Shell and you do whatever; in that order, so maybe a slight preferance towards ZFS.
Re: ZFS: Apple's new filesystem that wasn't (2016)
#114Earlier quoted context omitted.
If I recall correctly, ZFS error recovery was still “restore from backup” at the time, and iCloud acceptance was more limited. (ZFS basically gave up if an error was encountered after the checksum showed that the data was read correctly from storage media.) That's fine for deployments where the individual system does not matter (or you have dedicated staff to recover systems if necessary), but phones aren't like that…
ZFS has ditto blocks that allows it to self heal in the case of corrupt metadata as long as a good copy remains (and there would be at least 2 copies by default). ZFS only ever needs you to restore from backup if the damage is so severe that there is no making sense of things. Minor things like the indirect blocks being missing for a regular file only affect that file. Major things like all 3 copies of the MOS (the e…
As far as I understand it, ditto blocks were only used if the corruption was detected due to checksum mismatch. If the checksum was correct, but metadata turned out to be unusable later (say because it was corrupted in memory, and the the checksum was computed after the corruption happened), that was treated as a fatal error.
Re: ZFS: Apple's new filesystem that wasn't (2016)
#115Besides 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.
This seems like an early application of the Tim Cook doctrine: Why would Apple want to surrender control of this key bit of technology for their platforms? The rollout of APFS a decade later validated this concern. There’s just no way that flawless transition happens so rapidly without a filesystem fit to order for Apple’s needs from Day 0.
Using ZFS isn't surrendering control. Same as using parts of FreeBSD. Apple retains control because they don't have an obligation (or track record) of following the upstream.
For zfs, there's been a lot of improvements over the years, but if they had done the fork and adapt and then leave it alone, their fork would continue to work without outside control. They could pull in things from outside if they want, when they want; some parts easier than others.
Re: ZFS: Apple's new filesystem that wasn't (2016)
#116Earlier quoted context omitted.
Unlike other out of tree filesystems such as Reiser4, the ZFS driver does not patch the kernel sources.
That is due to licensing reasons, yes. It makes maintaining the codebase even more complicated because when the kernel module API changes (which it very frequently does) you cannot just adapt it to your needs, you have to work around all the new changes that are there in the new version.
You have things backward. Licensing has nothing to do with it. Changes to the kernel are unnecessary. Maintaining the code base is also simplified by supporting the various kernel versions the way that they are currently supported.
Re: ZFS: Apple's new filesystem that wasn't (2016)
#117Earlier quoted context omitted.
RedHat’s policy is no out of tree kernel modules, so it would not have made a difference.
It’s not like Red Hat had/has no influence over what makes it into mainline. But the options for copy on write were either relatively immature or had license issues in their view.
Their view is that if it is out of tree, they will not support it. This supersedes any discussion of license. Even out of tree GPL drivers are not supported by RedHat.
Re: ZFS: Apple's new filesystem that wasn't (2016)
#118Earlier quoted context omitted.
> There was nothing that specific about Solaris that made sense for ZFS, and even less of a connection to the SPARC architecture. Although it does not change the answer to the original question, I have long been under the impression that part of the design of ZFS had been influenced by the Niagara processor. The heavily threaded ZIO pipeline had been so forward thinking that it is difficult to imagine anyone devising…
Niagara did not shape design decisions at all -- remember that Niagara was really only doing on a single socket what we had already done on large SMP machines (e.g., Starfire/Starcat). What did shape design decisions -- or at least informed thinking -- was a belief that all main memory would be non-volatile within the lifespan of ZFS. (Still possible, of course!) I don't know that there are any true artifacts of that…
Thanks. I had been unaware of the Starfire/Starcat machines.
Re: ZFS: Apple's new filesystem that wasn't (2016)
#119Earlier quoted context omitted.
> disks are not checked for correctness, basically ever on any machine anywhere. I'm not sure that's really accurate -- all modern hard drives and SSD's use error-correcting codes, as far as I know. That's different from implementing additional integrity checking at the filesystem level. But it's definitely there to begin with.
But SSDs (to my knowledge) only implement checksum for the data transfer. Its a requirement of the protocol. So you can be sure that the Stuff in memory and checksum computed by the CPU arrives exactly like that in the SSD driver. In the past this was a common error source with hardware raid which was faulty. But there is ABSOLUTELY NO checksum for the bits stored on a SSD. So bit rot at the cells of the SSDs are und…
All MLC SSDs absolutely do data checksums and error recovery, otherwise they would very lose your data much more than they do.
You can see some stats using `smartctl`.
Re: ZFS: Apple's new filesystem that wasn't (2016)
#120The death of ZFS in macOS was a huge shift in the industry. This has to be seen in the context of microsoft killed their largely ambitious WinFS which felt like the death of desktop innovation in combination.
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.
I remember eagerly anticipating ZFS for desktop hard disks. I seem to remember it never took off because memory requirements were too high and payoffs were insufficient to justify the trade off.