Hacker News Reader

Comment by kissgyorgy | Hacker News Reader

Last year when I wanted to build a 10 disk ZFS server in RAIDZ2 and researched about the data-integrity and fault-tolerance aspects, I found this video of guys literally making hardware failure by conducting electricity into the motherboard attached to a RAIDZ2 array:

https://www.youtube.com/watch?v=vxFNBZIAClc

and they could not make any errors. This was pretty brutal. When I saw this video, I decided I never want to use any other filesystem than ZFS ever.

View on HN

I think irradiating the system would be a better test since it would induce random bitflips anywhere in the system while it is keeps running and reading/writing data instead of inducing a massive fault that will almost immediately stop any IO operations.

Overclocking some components might work too.

Worked at a major switch vendor as one of the 50 original staff. We put our gear through a ton of test - 4 corners - low power high heat, high power low heat, etc. One of the most interesting was taking the device to a government lab here in NorCal in order to shoot radioactive particle into the board while passing packets. It was pretty cool. The goal was to test TCAM and switch OS RAM to see how it handle bit flips. It passed. The board itself, well we could not have it back for a few weeks to allow it to "cool". The other thing of note was winning a US gov. contact was to enable commands to override any heat related auto shutdown. We were told "look, if the device is in a situation where this is an issue, burn it up but keep it working as long as you can". This was for navy ships.

Sometimes referred to as "Battleshort"[1] mode

[1] https://en.wikipedia.org/wiki/Battleshort

> burn it up but keep it working as long as you can

I mean, if the ship is on fire, you want the missile control systems to shut down after all missiles have been fired.

It wouldn’t matter. An error would have to occur in such a way as to also corrupt the data and the checksum in such a way that the corrupted checksum is valid for the errant block.

Not sure why the downvotes, this is in fact how it works and why ZFS doesn't need ECC Ram. It doesn't matter how much corruption you experience it always comes down to does the checksum of the block of data read from disk match the checksum stored when that block was written. If either mismatch, then the block is rebuilt from parity drives. If you're going to downvote, at least say why.

You still want ECC to make sure the data doesn't get corrupted on the way in or on the way out. ZFS will store what you send it, and it isn't responsible for your data once in hands it to you.

The best part about ECC RAM, IMO, isn't the correction, but the checking. I want to know when my RAM goes bad, and I'd prefer to know before ZFS detects a problem.

I'm so sick of this argument every time a ZFS article comes up.

This is by the inventor, Matthew Ahrens: “There’s nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem.”

https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-y...

Now give me my karma back.

The comment from the inventor isn't supporting your position. ZFS doens't need it any more, but if you care about data integrity, then you want ECC memory in your system. Yes, ZFS can take care of errors while it inside the ZFS API boundary, but the data on the outside of that is at risk, unless you have some higher level error correction protocol going on.

Don't make the mistake of thinking Non-ECC ram doesn't have built-in error protection it's just not as robust. Random memory bit flips are pretty rare but it takes multiple at the same time for ECC to be effective. Additionally, the thing that makes no sense about ECC Ram is that you have no parity checks when data is in transit too and from the CPU(s). So a little corrosion on a trace or bad capacitor and ECC Ram won't be able to do anything about it.

This goes against all available information on ECC on the internet. Source?

https://en.wikipedia.org/wiki/Parity_bit

Furthermore, there is error correction at the chip level. I think a fitting analogy is like this: A single-engine airplane might seem much more dangerous than a dual engine airplane, but most single-engine airplanes have dual fuel pumps, dual ignitions sources, and additional auxiliary devices sharing the same engine body. Will it ever be as safe as a dual engine plane, no, but it's not as dangerous as having no failsafes.

From the linked article:

Modern RAM is believed, with much justification, to be reliable, and error-detecting RAM has largely fallen out of use for non-critical applications. By the mid-1990s, most DRAM had dropped parity checking as manufacturers felt confident that it was no longer necessary.

It's you who is making the mistake. Non-ECC RAM does not have any protection. Prove me wrong, describe the mechanism.

https://en.wikipedia.org/wiki/RAM_parity

From that article:

"The SDRAM and DDR modules that replaced the earlier types are usually available either without error-checking or with ECC (full correction, not just parity)."

"ECC (full correction, not just parity)" - meaning byte level parity is standard whereas a cache line checksum is extra.

The thing about ECC vs. non-ECC. If you don't have ECC, you don't know silent bit corruption is happening, and when it's finally (if it's ever) discovered, there's nothing that can be done. ECC (SECDED) keeps data safer than it would be otherwise.

ECC is necessary for anything real or important based on the financial cost of losing data. For everything else, it can be optional.

Plus, don't forget the security issues of bitsquatting and other attacks that are the real results of silent bitflips.

DEF CON 19 - Artem Dinaburg - Bit-squatting: DNS Hijacking Without Exploitation https://youtu.be/9WcHsT97suU

All computers do error checking. Here is a summary:

Non-ECC - Checksum: parity bit BlockSize: 1 byte

ECC - Checksum: 7 bits BlockSize: 8 bytes

ZFS - Checksum: 256 bits BlockSize: ~128kb

It’s a lot further than this though with unbuffered RAM, registered RAM in the mix affecting performance and such. Error detection and error correction are different and require different levels of parity codes. Standard RAM at one point (SIMMs in the 90s) detected errors but won’t ever correct them. ECC can detect more but error patterns and now correct error patterns up to so many bits.

The issues are more subtle beyond hardware though - your OS kernel has to understand the detection from the BIOS / EFI and if the motherboard manufacturer decided not to opt for wiring in the checksum fail signal you will run blind to data corruption that’s potentially really subtle on typical consumer hardware. With some BIOSes RAM failures result in a hard panic and will hard reboot the machine (the idea being a crash is better than continuing with an error).

For me, ECC (both UDIMM and RDIMM) today are so inexpensive it’s a no-brainer for builds for business.

Can't speak for the downvoters, but I think what beatgammit is saying is that, in cases where you care about data corruption in ZFS, you also care about data corruption in parts of the system that aren't ZFS. Like the memory maps of every piece of application software. Nothing about ZFS needs ECC, but the circumstances ZFS claims to protect against need ECC.

Exactly! You build a system with ZFS, because you need better defense against corruption, but without ECC, RAM will be the weak point in the system, so if you want the same level of guarantees, you need ECC, not because of ZFS.

How so? You have a file from source A acquired via network, external storage, disc, etc and you want to store it on a ZFS array. If the ram corrupts the file before ZFS can store it, then the destination checksum will not match the source checksum. In reverse, you load the file from ZFS and ram corrupts the data before transit, then the transmitted file's checksum will not match the source's checksum. In either event, a retry will likely solve the issue as its unlikely for the same exact bytes of physical memory to be used over and over again

> the destination checksum will not match the source checksum

There is no source checksum.

> transmitted file's checksum will not match the source's checksum

Most applications don't checksum their files when reading them.

> a retry will likely solve the issue

You can't retry; the only copy of the edited file is corrupt, and it's not possible to (automatically, in the general case) distinguish edits you made since loading the file out of ZFS from memory corruption that happened since loading the file out of ZFS.

That's not how ZFS works.

No ZFS never protects against data in transit. It makes 1 promise, that the bytes written to disk will be the same bytes read from disk at a later point in time. ZFS can't be responsible for being given bad data. Corrupt data looks just as writable as normal data to a storage controller. The article I linked shows how even bad ram isn't damaging to the integrity of a properly configured ZFS file system.

1. ZFS is heavy on memory, vastly increasing the odds that a failure will happen during filesystem operations. This is something many learnt while both encrypting their drives and overclocking their CPU. Encrypting your drives makes the CPU spend orders of magnitude more time processing filesystem data, and if an error is about to happen it is orders of magnitudes more likely you will have corrupt data because of it. Same goes with memory.

2. If an error occurs on ZFS the consequences are worse, because there are very limited recovery-tools available for ZFS. The official checkdisk is "just restore from tape, it's quicker than fsck anyway". Very enterprise oriented.

Now you might be okay with the above. But the risk is greater and the potential consequences are worse. Not because of ZFS being special, but because of the way it makes use of your hardware.

Also keep in mind that a lot of people pick ZFS to reduce potential corruption so the addition of ECC is par for the course.

Just because ZFS isn't an exception doesn't mean ECC RAM is any less desirable for filesystems in general.

this is cool, but I have to wonder how much of this is ZFS and how much is the hardware. don’t get me wrong: it’s impressive, but to make the claims about ZFS you need to have a scientific approach that would involve a control group, various types of motherboards, memories, power supplies, etc + thorough reproducibility of the conditions.

Anecdote, but I had once a broken SATA controller that would send borked data to the disks. That was tricky because the disks were correctly writing the data sent to them and from the OS side all the operations were completed successfully. I realized that only because there was a continuous stream of checksum errors on all the disks of the pool.

Had this same problem too. Compared two sata controllers and noticed one was missing an inductor from the board. Amazing it worked at all

Same. Specifically, I the fault is inserted in a way which may never even manifest at zfs level. Any relevant failures could be more reliably replicated by injecting read/write failures and by writing random bytes to the disk. What else would you expect zfs to correct? Whether it worked out not can be read back from the error counters.

Ha! That reminds me of the "Yelling at the Fileserver" video.

https://www.youtube.com/watch?v=tDacjrSCeq4

Did they even perform any file (write)operations when testing? If not that was a waste of time... FAT32 would have performed just as well.

that is just a sensational science video. there’s no testimony given that normal raid5 wouldn’t have survived exactly as well. he needed to have mentioned what happened on reboot fatter running a scrub.

well not exactly true. we know that the raid5 write hole won’t tolerate random power off / memory removal etc.

as someone else said, x ray test would have been better.

Reply on news.ycombinator.com