Re: RN316, no DBs: Bit-Rot Protection + Compression = No-Brainer?
Personally I leave compression off. I have bit-rot protection turned on.
Compression won't help very much (if at all) on your media files, since they are already compressed. So all that is likely to do is add overhead. It will help on the document shares, but those likely aren't taking much space.
Re: RN316, no DBs: Bit-Rot Protection + Compression = No-Brainer?
I wouldn't bother to use Bit Rot protection or compression on shares that hold videos.
On shares for document, bit rot protection is good on paper. But it may imply a high level of fragmentation, so appropriate volume maintenance is advisable.
I personnally do not use bit rot protection on any share. I could, because it wouldn't result in huge fragmentation in my use case, and perhaps should, because it would be good to have even the slightest protection against bit rot, but I don't, because I haven't seen many case where it actually helped while seen some cases where the metadata allocation got out of hand.
If you believe you need to use bit rot protection, or even just want to use it, then you should probably use it. But I wouldn't use it on every share either. A corrupted movie is not much of an issue, but losing the very first photo of a child would be.
Re: RN316, no DBs: Bit-Rot Protection + Compression = No-Brainer?
It looks to me like I cannot turn on Compression unless Bit-Rot Protection is turned on: the "Compression" checkbox is disabled with Bit-Rot turned off.
On shares for document, bit rot protection is good on paper. But it may imply a high level of fragmentation, so appropriate volume maintenance is advisable.
Are you saying that bit rot protection increases fragmentation even when snapshots are on?
On shares for document, bit rot protection is good on paper. But it may imply a high level of fragmentation, so appropriate volume maintenance is advisable.
Are you saying that bit rot protection increases fragmentation even when snapshots are on?
Yes, noCoW doesn't disable Copy-on-Write, it "disables CoW if possible".
If CoW is disabled, and there is no snapshot, all writes will be committed in the existing blocks, in place.
If CoW is disabled, and there is snapshot(s), the first write after the snapshot will be in a new block, the second will be in the same one. If a new snapshot is taken, repeat the logic. I've heard this being refered to as "Half-CoW", which I find describes well the behavior, it's "only CoW if necessary".
If CoW is enabled, ALL writes will be committed to a new block, EVERY time, snapshot or not.
Bit rot protection is based on the checksums. If you disable Copy-on-Write, there are no checksums.
It's also important to note that toggling the nocow flag on existing (non-empty) files does NOT change the behavior for that file. This also applies to the nodatacow mount option, which affects only newly created files (and, iirc, empty files), and implies nodatasum.
And that will create fragmentation if snapshots are off. But I'm not seeing how the fragmentation is worse if snapshots are on.
It's not.
The "worst" case scenario is when CoW is on. If you turn on bit rot protection, you turn on CoW.
I know that. But I get essentially the same fragmentation with snapshots on but bit rot protection off - at least that's the conclusion I'm drawing from your analysis.
The only case where fragmentation would be increased is
a new file is written
that file is updated before a snapshot is taken
Based on your description, that update would fragment the file with bit-rot protection on, but would not fragment with bit-rot protection off.
In any event, it is clear that bit-rot protection should be off if the share isn't suitable for snapshots (e.g., torrent folders, live databases, etc).
