Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZFS: Apple's new filesystem that wasn't (2016)

ahl.dtrace.org

Post reply on HN
Print view View original

41–50 of 209 posts

Re: ZFS: Apple's new filesystem that wasn't (2016)

#41

Post by amarshall »

thfuran wrote: post #21
Dylan16807 wrote: post #17

Earlier quoted context omitted.

> ZFS is notorious for corrupting itself when bit flips hit it and break the checksum on disk I don't think it is. I've never heard of that happening, or seen any evidence ZFS is more likely to break than any random filesystem. I've only seen people spreading paranoid rumors based on a couple pages saying ECC memory is important to fully get the benefits of ZFS.

They also insist that you need about 10 TB RAM per TB disk space or something like that.

It’s unfortunate some folks are missing the tongue-in-cheek nature of your comment.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#42

Post by amarshall »

thfuran wrote: post #34
yjftsjthsd-h wrote: post #29

Earlier quoted context omitted.

There is a rule of thumb that you should have at least 1 GB of RAM per TB of disk when using deduplication . That's.... Different.

So you've never seen the people saying you should steer clear of ZFS unless you're going to have an enormous ARC even when talking about personal media servers?

Even then you obviously need L2ARC as well!! /s

Re: ZFS: Apple's new filesystem that wasn't (2016)

#43

Post by toast0 »

thfuran wrote: post #34
yjftsjthsd-h wrote: post #29

Earlier quoted context omitted.

There is a rule of thumb that you should have at least 1 GB of RAM per TB of disk when using deduplication . That's.... Different.

So you've never seen the people saying you should steer clear of ZFS unless you're going to have an enormous ARC even when talking about personal media servers?

People, especially those on the Internet, say a lot of things.

Some of the things they say aren't credible, even if they're said often.

You don't need an enormous amount of ram to run zfs unless you have dedupe enabled. A lot of people thought they wanted dedupe enabled though. (2024's fast dedupe may help, but probably the right answer for most people is not to use dedupe)

It's the same thing with the "need" for ECC. If your ram is bad, you're going to end up with bad data in your filesystem. With ZFS, you're likely to find out your filesystem is corrupt (although, if the data is corrupted before the checksum is calculated, then the checksum doesn't help); with a non-checksumming filesystem, you may get lucky and not have meta data get corrupted and the OS keeps going, just some of your files are wrong. Having ECC would be better, but there's tradeoffs so it never made sense for me to use it at home; zfs still works and is protecting me from disk contents changing, even if what was written could be wrong.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#44

Post by amarshall »

zie wrote: post #27
mrkeen wrote: post #20

Earlier quoted context omitted.

> ZFS is notorious for corrupting itself when bit flips hit it and break the checksum on disk. What's a bit flip?

Basically it's that memory changes out from under you. As we know, computers use Binary, so everything boils down to it being a 0 or a 1. A bit flip is changing what was say a 0 into a 1. Usually attributed to "cosmic rays", but really can happen for any number of less exciting sounding reasons. Basically, there is zero double checking in your computer for almost everything except stuff that goes across the network.…

Btrfs and bcachefs both have data checksumming. I think ReFS does as well.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#45

Post by tpetry »

crazygringo wrote: post #38
zie wrote: post #27

Earlier quoted context omitted.

Basically it's that memory changes out from under you. As we know, computers use Binary, so everything boils down to it being a 0 or a 1. A bit flip is changing what was say a 0 into a 1. Usually attributed to "cosmic rays", but really can happen for any number of less exciting sounding reasons. Basically, there is zero double checking in your computer for almost everything except stuff that goes across the network.…

> 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 undetected.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#46

Post by thyristan »

em500 wrote: post #40
thyristan wrote: post #35

Earlier 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.

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 enthusiasts with the right usecases are very few.

And for the thin-provisioned snapshotted subvolume usecase, btrfs is currently eating ZFS's lunch due to far better Linux integration. Think snapshots at every update, and having a/b boot to get back to a known-working config after an update. So widespread adoption through the distro route is out of the question.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#47

Post by secabeen »

ZFS remains an excellent filesystem for bulk storage on rust, but were I Apple at the time, I would probably want to focus on something built for the coming era of flash and NVMe storage. There are a number of axioms built into ZFS that come out of the spinning disk era that still hold it back for flash-only filesystems.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#48

Post by wkat4242 »

em500 wrote: post #40
thyristan wrote: post #35

Earlier 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.

That's called marketing. Give it a snazzy name, like say "TimeMachine" and users will jump on it.

Also, ZFS has a bad name within the Linux community due to some licensing stuff. I find that most BSD users don't really care about such legalese and most people I know that run FreeBSD are running ZFS on root. Which works amazingly well I might add.

Especially with something like sanoid added to it, it basically does the same as timemachine on mac, a feature that users love. Albeit stored on the same drive (but with syncoid or just manually rolled zfs send/recv scripts you can do that on another location too).

Re: ZFS: Apple's new filesystem that wasn't (2016)

#49

Post by kmeisthax »

twoodfin wrote: post #8
jitl wrote: post #2

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.

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.

To be clear, BTRFS also supports in-place upgrade. It's not a uniquely Apple feature; any copy-on-write filesystem with flexibility as to where data is located can be made to fit inside of the free blocks of another filesystem. Once you can do that, then you can do test runs[0] of the filesystem upgrade before committing to wiping the superblock.

I don't know for certain if they could have done it with ZFS; but I can imagine it would at least been doable with some Apple extensions that would only have to exist during test / upgrade time.

[0] Part of why the APFS upgrade was so flawless was that Apple had done a test upgrade in a prior iOS update. They'd run the updater, log any errors, and then revert the upgrade and ship the error log back to Apple for analysis.

Re: ZFS: Apple's new filesystem that wasn't (2016)

#50

Post by Modified3019 »

jeroenhd wrote: post #11

I wonder what ZFS in the iPhone would've looked like. As far as I recall, the iPhone didn't have error correcting memory, and ZFS is notorious for corrupting itself when bit flips hit it and break the checksum on disk. ZFS' RAM-hungry nature would've also forced Apple to add more memory to their phone.

ZFS detects corruption.

A very long ago someone named cyberjock was a prolific and opinionated proponent of ZFS, who wrote many things about ZFS during a time when the hobbyist community was tiny and not very familiar with how to use it and how it worked. Unfortunately, some of their most misguided and/or outdated thoughts still haunt modern consciousness like an egregore.

What you are probably thinking of is the proposed doomsday scenario where bad ram could theoretically kill a ZFS pool during a scrub.

This article does a good job of explaining how that might happen, and why being concerned about it is tilting at windmills: https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-y...

I have never once heard of this happening in real life.

Hell, I’ve never even had bad ram. I have had bad sata/sas cables, and a bad disk though. ZFS faithfully informed me there was a problem, which no other file system would have done. I’ve seen other people that start getting corruption when sata/sas controllers go bad or overheat, which again is detected by ZFS.

What actually destroys pools is user error, followed very distantly by plain old fashioned ZFS bugs that someone with an unlucky edge case ran into.

Post reply on HN