How does bitrot protection actually work?

Do you guys know if using non-ECC memory with BTRFS and bitrot protection "on" has the ability to damage good data?

There has always been some discussion with ZFS that a scrub with non-ECC memory could potentially re-write the entire drive with bad data. I do not think that is true based on the method ZFS uses to replace data... it will not overwrite unless the new data iss confirmed good.

However, I do not understand the methodology for BTRFS scrubbing... is it the same as ZFS? Could a bad memory module without ECC casue the BTRFS to scrub the disk(s) with bad data?

Bad memory in the NAS can always corrupt the file system. It doesn't matter what the file system is (ZFS, BTRFS, EXT, ...).

Yes, but there has been discussion that non-ecc memory could corrupt an entire volume systematically.

During a scrub, the data is regularly checked for bit-rot and if the memory is bad, it would calculate bit rot (incorrectly)...then replace good data with bad data.

ZFS wont do that based on the way it replaces the "bad" memory spot (It would have to find something it calculates as "good" to replace the bad, and bad memory would never find something "good" to use).

But how does Netgear's implementation of BTRFS do that?

Well, I am very skeptical that the bad non-ecc memory would magically fail systematically on the checksum and nothing else.

Having said that, I believe Netgear's implementation repairs bitrot using the RAID protection. So if the checksum fails to validate, it attempts to rebuild the sector that failed from the other RAID blocks in that stripe. If that doesn't result in a checksum that passes, then the bitrot repair fails. That sounds similar to the way you describe ZFS.

Of course, once either approach finds something good to use, that pesky bad memory might just corrupt it before it gets rewritten. So I am sticking with my position that bad memory can corrupt any file system. It seems to me that the simplest way to corrupt the volume with bad memory is on the initial write (the data being corrupted in memory before it is ever written to the disk).

If you are concerned about the impact of non-ecc memory, then perhaps buy a readynas that has ecc (e.g., the RN516)

StephenB wrote:
If you are concerned about the impact of non-ecc memory, then perhaps buy a readynas that has ecc (e.g., the RN516)

Just to satisfy my curiosity as I have RN516.
If there was an error in the eec memory, would I know about it, or would it be hidden from the user?

I don't know for sure, but I believe corrected errors are logged.

StephenB wrote:
... If you are concerned about the impact of non-ecc memory, then perhaps buy a readynas that has ecc (e.g., the RN516)

I already have 3 ReadyNAS without ECC, so that is not an option until my next purchase.

I understand that bad memory can corrupt anything it writes, but most of my data is write once, save a long time, read often. Business records, photos, etc.

My concern is turning the bit rot protection on and then, due to bad memory, having every checksum fail during a scrub. This could conceivably cause a re-write of an entire disk with the bad memory. Then in one shot I have corrupted everything.

What do you think?

I don't think that's possible. If the checksums at the filesystem level are all bad then one would expect the checksums at the md level to all be bad as well.

In any case bitrot protection is a great feature, but backups are still important. No important data should be stored on just the one device.

mdgm wrote:
I don't think that's possible. If the checksums at the filesystem level are all bad then one would expect the checksums at the md level to all be bad as well.

I think I understand...

Just so I am clear, the process would be that the bit rot protection routine first checks the primary data, then, if it finds an error, it goes out to the redundant data location and checks THAT data.

It will only write from the redundant location to the original location if it finds a correct checksum at the redundant location.

If it finds an incorrect checksum at both locations (it will find both locations incorrect, since the memory is defective) then no data is written and an error is generated.

This is the way the ZFS system works and inspires confidence. Do I have it correct?

mdgm wrote:
In any case bitrot protection is a great feature, but backups are still important. No important data should be stored on just the one device.

I am with you. Minimum of three (3) copies with at least one off site.

However, you can easily corrupt multiple copies if your primary source gets damaged by the file system and you do not know. As an example:

-On day 1, I have (3) 1TB drives A, B, & C with the same info.

-On day 2, copy A is damaged systematically by the file system without me knowing (but the drive is fine with no SMART errors).

-On day 3, drive B fails in the normal way, so I copy my data from drive A to drive B.

sgogo wrote:

Just so I am clear, the process would be that the bit rot protection routine first checks the primary data, then, if it finds an error, it goes out to the redundant data location and checks THAT data. It will only write from the redundant location to the original location if it finds a correct checksum at the redundant location. If it finds an incorrect checksum at both locations (it will find both locations incorrect, since the memory is defective) then no data is written and an error is generated. This is the way the ZFS system works and inspires confidence. Do I have it correct?

Yes