Mini NASes marry NVMe to Intel's efficient chip

I’m a TrueNAS/FreeNAS user, currently running an ECC system. The traditional wisdom is that ECC is a must-have for ZFS. What do you think? Is this outdated?

One way to look at it is ECC has recently become more affordable due to In-Band ECC (IBECC) providing ECC-like functionality for a lot of newer power efficient Intel CPUs.

https://www.phoronix.com/news/Intel-IGEN6-IBECC-Driver

Not every new CPU has it, for example, the Intel N95, N97, N100, N200, i3-N300, and i3-N305 all have it, but the N150 doesn't!

It's kind of disappointing that the low power NAS devices reviewed here, the only one with support for IBECC had a limited BIOS that most likely was missing this option. The ODROID H4 series, CWWK NAS products, AOOSTAR, and various N100 ITX motherboards all support it.

That traditional wisdom is wrong. ECC is a must-have for any computer. The only reason people think ECC is mandatory for ZFS is because it exposes errors due to inherent checksumming and most other filesystems don't, even if they suffer from the same problems.

Been running without for 15+ on my NAS boxes, built using my previous desktop hardware fitted with NAS disks.

They're on 24/ and run monthly scrubs, as well as monthly checksum verification of my backup images, and not noticed any issues so far.

I had some correctable errors which got fixed when changing SATA cable a few times, and some from a disk that after 7 years of 24/7 developed a small run of bad sectors.

That said, you got ECC so you should be able to monitor corrected memory errors.

Matt Ahrens himself (one of the creators of ZFS) had said there's nothing particular about ZFS:

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

ECC is a must-have if you want to minimize the risk of corruption, but that is true for any filesystem.

Sun (and now Oracle) officially recommended using ECC ever since it was intended to be an enterprise product running on 24/7 servers, where it makes sense that anything that is going to be cached in RAM for long periods is protected by ECC.

In that sense it was a "must-have", as business-critical functions require that guarantee.

Now that you can use ZFS on a number of operating systems, on many different architectures, even a Raspberry Pi, the business-critical-only use-case is not as prevalent.

ZFS doesn't intrinsically require ECC but it does trust that the memory functions correctly which you have the best chance of achieving by using ECC.

Ultimately comes down to how important the data is to you. It's not really a technical question but one of risk tolerance

I'm curious if it would make sense for write caches in RAM to just include a CRC32 on every block, to be verified as it gets written to disk.

Don't you have to read that data into RAM before you can generate the CRC? Which means without ECC it could get silently corrupted on the way to the cache?

https://danluu.com/why-ecc/ has an argument for it with an update from 2024.

that's just as true with ecc as without

That makes sense. It’s my family photo library, so my risk tolerance is very low!