How does bitrot protection actually work?

StephenB:- I get the impression that you would recommend that 'bitrot protection' be turned ON. (Please say YES or NO)
If it is ON, does this cause extra wear and tear on the disks.
If it is OFF, are the snapshots real copies of the data rather than 'links' as for 'bitrot protection' ON.
I currently have 'bitrot protection' OFF and snapshots of 2GB are almost instantaneous.
I liked your comments, but am still not entirely sure what goes on, and the difference between when the facility is ON and OFF.
Confused!

I leave it on. Even if file errors can't be repaired, it will at least warn if when it finds something wrong. That might be a false alarm, but still it seems better to get the warning. Though honestly, I think that silent bitrot is quite rare, and its not something I'm particularly concerned about in my OS 4 NAS. One reason I leave it on is just to see if it ever finds anything...

The cost of bitrot protection itself is that btrfs checksums are enabled. So they are checked during file reads, and updated during file writes. There might be a small performance hit on the RN516 - its easy enough to measure any performance impact, since you can create two shares; enabling on one but not the other.

Creating snapshots is always near-instantaneous. Any performance problems they create happen later on, when files in the main share are modified. Then files in the main share get fragmented - and that fragmentation eventually migrates to the snapshots. I leave daily snapshots enabled on most shares despite that possibility. But most of my files aren't modified in place, and I do have defrag, balance, scrubs, and disk checks scheduled in the maintenance schedule (each is run once every three months on each volume).

But if you do have files that are frequently modified in place (downloading torrents, SQL databases, or something like that), then you will want to turn bitrot protection off on those shares. That's becaue Netgear links CoW with BTRFS checksum protection, the GUI doesn't control them independently. The problem is the CoW fragmentation, not the checksum overhead.

To your specific questions:
-bitrot protection by itself does not cause extra wear and tear on the disk. If you end up with fragmentation, then the disks will do more seeking when you read the files, and the balance and defrag maintenance tasks will likely take longer to complete. I don't think that hurts disk life, at least I've never seen studies that claim that.

-snapshots always share file datablocks with each other and the parent share. Bitrot protection doesn't change that. If bitrot protection is off, then CoW is turned on before every snapshot is taken, and turned off after the snapshot completes. If bitrot protection is on, then CoW is on all the time.

To start with: bitrot protection (knowing it is a feature of btrfs) was one of my selection criteria for a ReadyNas 104.

I was quite disappointed as i recognized it wasn't supported with ReadyNas OS <6.2 as i started and i fiddled a bit on system level to check what i can do, and manually reballanced the btrfs filesystem behind the JBOD X-Raid mode of readynas to have BTRFS-RAID-1 that supports bit-rot-protection.

The Bit-Rot-Protection that is now available in Readynas OS6.2 is very weird and doesn't make sense to me: I currently have a JBOD volume over 2 3TB Drives.

The UI allows me to turn on Bit-Rot-Protection on share level. I can't understand how this could work at all - it can give me an message if a file is corrupted, but it can't protect me against it and rebuild mismatching blocks, as no redundancy is enabled at the moment.

I tryed to peek behind the User Interface to get a knowledge of what is going on... but really, i don't know exactly.

There is a interesting utility & daemon: mdcsrepair & mdcsrepaird. It seems to be tied into the linux md system somehow... The name could mean "md checksum repair".
This would be basically what bitrot protection stands for, but i don't understand how it can be enabled per subvolume of the btrfs filesystem, when the md volumes are beneath the btrfs filesystem.

Some clarification of the technical point of "bit-rot-protection" in ReadyNas would be greatly appreciated!

You need to be using a md raid level that provides redundancy.

Our bit rot protection requires redundancy at the md raid layer whereas BTRFS by itself would require redundancy on the BTRFS layer. We achieve the same thing but in a different way.

We use btrfs checksums and use the md layer to find the correct block.

Bitrot protection is suitable for some use cases and can be quite resource intensive. So only using it on shares for which it is appropriate to use it with is good.

Bitrot protection works best with data that has minimal in place modifications. it is there to protect against degradation.

mdgm wrote:
Bitrot protection is suitable for some use cases and can be quite resource intensive. So only using it on shares for which it is appropriate to use it with is good.

Overall, I think its frustrating for RN100 series users to be told repeatedly "hey, all these features in the GUI - they aren't for you...". Netgear should provide some real data on the performance impacts of checksums, AntiVirus, RAID-6 on all platforms. Then users can figure out if the benefits outweigh the costs for them, and make better choices on their platform investments,

Do you mean the repair is resource intensive, or the the protection itself (checksums + CoW)?

I'm not seeing much impact on my RN102, which leads me to think that the issue you are talking about is CoW fragmentation. That of course is not easily quantified - and fragmentation kills performance on all platforms.

Seeing repair is not all that constant I would think it would be the CoW fragmentation as you mentioned.

Fragmentation doesn't happen more on slower platforms, but defrag time of course is longer. I think all OS6 users need to be thoughtful about CoW. If there's a way to report share-by-share fragmentation (and maybe even have a fragmentation alert) in OS6, that would be a good thing.

Generally speaking, on the lower end NAS you do need to trade off performance against features. That's the "cost" of getting the less expensive platform.

But there are lots of scenarios where this is acceptable for home users. If you are using WiFi, powerline, or fast ethernet then you are usually network bound anyway, so the performance hit isn't something you'll experience. And speed isn't the only consideration. Based on posts here, I'd personally avoid RAID-6 and SCSI LUNs on the RN100 series. But I see no reason to avoid the other features, as long as people understand that performance will drop if you turn on too much stuff.

Netgear already recommends RN300 or better for business users, which makes perfect sense to me. Some business can probably get by with less, but slower performance does translate into $$$ for most businesses.

mdgm wrote:
You need to be using a md raid level that provides redundancy.

Does that include RAID10 as like what I have on my RN516 with 6 x 4TB.
Or are you talking about RAID5 and RAID6 only.

BaJohn wrote:
mdgm wrote: You need to be using a md raid level that provides redundancy. Does that include RAID10 as like what I have on my RN516 with 6 x 4TB. Or are you talking about RAID5 and RAID6 only.

Just to clarify your question - I think you are actually wanting to know if the bitrot protection is supported for RAID-10?

StephenB wrote:
...I do have defrag, balance, scrubs, and disk checks scheduled in the maintenance schedule (each is run once every three months on each volume).

Could you advise the optimum order for the
1. Disk Defragmentation
2. Disk Balance (Not certain what this means - comment please?)
3. Data Scrubbing (Incorrectly described as Disk Scrubbing in the forums, which is something else entirely)
4. Disk Checks (CHKDSK ?)
if you do these end to end (or a day apart, say).
OR
do you spread them randomly/evenly through your 3 month period?