Hacker News Reader

Comment by zoky | Hacker News Reader

In what way isn’t it? Any potential shortfalls could have been made up with a little bit of engineering elbow grease.

What are the advantages APFS has over ZFS, for lightweight systems or otherwise?

> The APFS engineers I talked to cited strong ECC protection within Apple storage devices. Both NAND flash SSDs and magnetic media HDDs use redundant data to detect and correct errors. The Apple engineers contend that Apple devices basically don't return bogus data. NAND uses extra data, e.g. 128 bytes per 4KB page, so that errors can be corrected and detected. (For reference, ZFS uses a fixed size 32 byte checksum for blocks ranging from 512 bytes to megabytes. That's small by comparison, but bear in mind that the SSD's ECC is required for the expected analog variances within the media.) The devices have a bit error rate that's low enough to expect no errors over the device's lifetime.

https://arstechnica.com/gadgets/2016/06/a-zfs-developers-ana...

Dominic Giampaolo wrote BeFS, Spotlight, and now APFS.

In my 15-ish years running ZFS at home, the only time I’ve had corruption was when there was also noticeable hardware issues (cables, drives, enclosures). ZFS made them easy to deal with, but wouldn’t have helped if I wasn’t already running RAIDZ or mirrors. I’ve not looked recently, but in the past ZFS was extremely RAM hungry and relatively CPU expensive, not necessarily something optimized for mobile devices or battery life.

ZFS expects to have a huge cache, and defaults to 50% of memory, separate to any other fs cache. For advanced features, it requires a certain amount of cache per TB of storage.

For single-disk non-checksummed, non-deduplicated storage, it's a lot of wasted code that a device with a "mere" gigabyte of RAM doesn't need. So APFS hits most of their needs: volume management + journal + better disk layout for SSD.

Am noob. But as I understand it:

ZFS features like dedupe and data protection require a lot of RAM and run in the background;

filesystems optimized for different medias (HDD, SDD, WORM, etc) make different design choices.

Dedupe is an optional and often misunderstood feature. It's a solution to a niche problem and not something you should enable because it exists. Data protection doesn't require lots of memory, but the way it's implemented means you can't just use the file system cache to back memory mapped files 1:1 like you can with a less reliable file system that modifies file content in place without checksumming. ZFS doesn't have to be the memory hog it's made out to be. A lot of the issues with ZFS on 32bit systems come from the fact that pre Meltdown the kernel heap had to fit into <1GiB of the address space shared with memory-mapped I/O. Often its cache hat to be restricted to ~300MiB and tried to allocate 128kiB continuous buffers from that since it was designed for 64bit virtual address spaces there was no support for chaining multiple smaller allocations to back a large block.

Reply on news.ycombinator.com