6.2.0 has no manual to download

The 6.2 scheduler gives you a lot of flexibility on this.

Scrub also serves as a disk diagnostic (every sector in the volume is read), so you probably should take that into account in your schedule.

Maybe start with a once per quarter pace for each. Something like
Scrub 1/1, 4/1, 7/1, 10/1
Defrag 2/1, 5/1, 8/1, 11/1
Test 2/15, 5/15, 8/15, 11/15
Balance 3/1, 6/1, 9/1, 12/1

That does a full disk exercise every 6-7 weeks.

I start mine at 2 am (which is after my RN102 backup jobs complete).

I have an RN104 with 4 - 4tb drives in xraid 5 mode.

I am going to run scrub once every other month,

And then run balance , and defrag once a week.

As I delete and add large files on a regular basis about a dozen a week, some times more sometimes less

A better approach when adding and deleting large files regularly would probably be to disable CoW and snapshots on that share.

I think it depends a lot on the pattern of I/O to those files. If it's sequential write and random reads, then it really shouldn't be a problem. But if those large files were undergoung random read/writes or were growing slowly over time -- such as might happen with a multi-GB VM disk file -- then turning off CoW might yield real performance benefits. I don't tend to run VMs from NAS storage, but on my Linux workstation running BtRFS, I disabled CoW on the folder tree containing my VMs for exactly this reason. For shares where I store large bitorrented files, which aren't modified but do receive random read activity, I wouldn't worry one bit about having CoW enabled.

As far as I can see it doesn't have much to do with random io or growth. It's all about the file changing.

When CoW is enabled, every time the file changes, the older data gets copied into the current snapshot.

If the file is a database or a downloading torrent that is changing hundreds and hundreds of times, the consequences should be pretty obvious.

But of course once e.g. a Linux ISO is downloaded you could copy it to a share with CoW as it won't change much after it is downloaded.

Which both sort of make exactly my point. :) A DB or a large VM disk file will have a lot of random updates. CoW /isn't/ just a matter of what happens in snapshots, though that will certainly contribute. BtRFS (like ZFS) does CoW *in the filesystem itself*, regardless of snapshots. :) Now, for most Linux distros, that is enabled by default. Something that's a bit confusing in the settings for shares now is "BitRot protection (COW)"... so I presume this is our way of changing CoW on the share? Because it seems to be enabled separately from the snapshot schedule. (Note: This is where DOCUMENTATION is handy.)

And to mdgm's point, YES, that is an excellent example of a serial write of a large file (assuming you aren't, as StephenB pointed out, downloading it via bittorrent... which will cause blocks of the file to be written in random order and likely not preallocated. I don't know if most torrent clients allow for this, but it's most efficient to pre-allocate the file in one step and then write into at random locations and have CoW disabled. But at least if you can't preallocate and disable CoW, writing once is infinitely better than having a large file that you do random write I/O to (like DB or VM disk files).

It's a question of understand how different patterns of I/O impact the filesystem structures when CoW is active. ZFS has features that can rebalance as I/O is happening (rather than running a batch process to rebalance). But unless you're expecting particular performance out of the thing, CoW is probably not going to be hugely noticeable.

There were definitely some performance problems in earlier 6.x builds with snapshots. I have slowly re-enabled them on shares with 6.1.8 and 6.1.9 and found them to much more solid now. Since the upgrade to 6.2, all my pre-existing shares seem to reflect the expected CoW default with BtRFS. At least it's nice to know we can defeat it if desired. I do wonder how it behaves on an existing share if you disable it. The usual case is that you have to make new copies of every pre-existing file (once +COW is set) in order to properly disable it. Does the NAS do that? If not, it might be "better" to only let that option be flipped until there are files in the share (to make it clear that CoW isnt fully disabled in that case)...?

Anyway, whether one choosed to disable it (with or without snapshots) depends entirely on the workload and performance expectations. Most people will never know.

Bitrot protection depends on CoW. We have decided to have CoW disabled when Bitrot protection is disabled. Snapshots can still be taken when CoW is disabled. The snapshot will tell the FS to do CoW for the moment when it is taken.

If you don't want to use CoW you need to disable it on a share before putting the files in there. Disabling CoW won't affect existing files. There is a python script available on the web that can be used to disable CoW on files, but that relies on plenty of free space and copying the files to make it work.

OK... so that's basically a "yes" then. So are we just calling this something new, or is there an actual value add Netgear is calling "Bitrot Protection?"

Edit: And part of the reason I'm pressing the point is that CoW doesn't really do bitrot protection, though it has many other positive benefits.

Bitrot protection is not the same at all as CoW. It depends on CoW, but it is different.

With CoW every time you make a write it doesn't overwrite the existing file but writes to empty space. This is why files that are written to a lot can fragment quickly.

Bitrot protection makes use of the md raid layer and the filesystem layer to detect when a bit is flipped (e.g. a 1 swapped with a 0 corrupting a photo) and correct it.

Since early on with the ReadyNAS we have made sure to make maximum use of data protection provided by RAID.

For years as long as multiple drives don't lose data in the same stripe at the RAID level, we've always tried to recover data from good drives.

If different drives develop different bad sectors on different locations, we can still keep your data intact.

Today, with BTRFS checksums, we take this to another level. We not only know if data is corrupted, but we also try to pin down which portion of data is corrupted on which drive, and use RAID redundancy to kick out corrupted data and recover uncorrupted data.