Matt Ahrens:

“There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.”

https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=...

I'd say the main problem is that there isn't a fsck for ZFS. If important metadata gets damaged you'll have to re-create the whole file system.

W.r.t. to btrfs they are at least working on a fsck tool, even though it can't repair much yet (what it can repair is e.g. some bitflips caused by bad RAM: https://patchwork.kernel.org/patch/4116411/ ).

And stuff like ext4 or ntfs can get back to a state where one can write to it again in most cases.

Another problem is that many applications don't handle EIO well, i.e. they don't give you an option like "Continue with corrupt data", e.g. if a video file gets damaged it doesn't matter much, it'll just be a few damaged pixels, but the whole video player stops playback because it doesn't handle the IO error.

If there is any kind of corruption on a Btrfs file system, it will report EIO and path to the corrupt file, it will not handoff corrupt data to user space. The application can't really do that much but say something like I/O error, check kernel messages, or some such. It can't ask the kernel to continue with corrupt data, Btrfs driver has no such option.

Also, if metadata gets damaged, there is an option to roll back the filesystem to an earlier transaction using "zpool import -F".

I have been using ZFS for over two years, on any desktop that I control, as both root file system for FreeBSD setups and backup file system in many configurations. In almost all cases I don't have EEC ram and I don't need it really. Your comment is either outdated or wrong, ZFS is THE go-to filesystem on desktop for me.

Edit: oh and it works beautifully with single disk setups too.

Does anyone have any pointers to a resource for single disk ZFS setups? Last time I looked, most search results were entry points into a persistent flame war.

> In almost all cases I don't have EEC ram and I don't need it really.

That's like saying you don't need health insurance because you haven't got ill.

ECC is nice to have but absolutely not a show stopper if you don't have it. Plenty of articles and discussions online, example: http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-yo...

Claim that you can only use ZFS with ECC memory to feel safe is false.

Wait until you get a 1-bit flip in a spacemap record. Then you just won't be able to import your pool (insta-panic). And good luck with fining and fixing that flipped bit.

While it is indeed false that one needs ECC RAM to use ZFS, ECC by itself helps keep the data is memory safe.

I used to use non-ECC memory on my laptop when running Belenix, and I now use ECC memory on my servers at Hetzner where I run my own Illumos builds.

(I'm one of the maintainers of Belenix, an early opensolaris based distro that was the foundation of Solaris 11. I'm working on reviving it again)

There is this myth over the Freenas forums that ECC is a must-have for ZFS.

If you read closely the posts that are supposed to prove this claim, they never give strong evidence that the pool losses are directly linked to the lack of ECC memory.

It always ends up with cyberjoke stating that the issue was linked to lack of ECC.

Moreover, One of the OpenZFS developers confirms this is a myth here : https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=...

TL;DR: Zfs is as vulnerable as any other FS to bit flips. So if you care about your data, use ECC, regardless of your file system.

I have read a number of people talking about ECC and ZFS and the general consensus I have gleaned is the ECC is nice to have but not required.

How does btrfs keep data intact when the memory is broken better than ZFS and other filesystems?

you could add additional checks in the code to make sure the data is correct. the impression i got was that ZFS didn't add those checks because it would trust the RAM.

ZFS has no special reliance on ECC RAM: http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-yo...

TL;DR is that a few stuck bits is won't corrupt your pool like the forum post claims.

Also, in the highly unlikely event that bad RAM would make ZFS corrupt data, how would btrfs perform better on the same hardware?

Yes, I really hate that FUD. It makes people decide to use less safe filesystem because they don't have ECC RAM thinking ZFS somehow will corrupt their data, when in reality ZFS is still safe (and safer than other filesystems). ZFS claims to keep your data safe, but it can't prevent data being corrupted in RAM. If your RAM is corrupted your data might be as well no matter what filesystem you use. ECC RAM makes sure that memory is also safe and that ZFS can deliver its promises.