Originally Posted by jrwalte
All of those topics, except for 780, have to do with storage pooling and not what we are discussing in this thread, parity backup. And 780 had to do with encrypted files slowing down/failing the parity snapshot but not manipulating or corrupting the data. Storage pooling is a data management tool and will manipulate your data. Parity backup is not data management and it will not impact your existing data (only potentially lose/corrupt what you are trying to restore)
You describe pooling and parity as completely separate features, but under the hood, they are intertwined much more than you think.
- Deletes will compromise recovery UNLESS the operations are done through the storage pool and FlexRAID’s proprietary recycle bin feature is turned on
- Edits WILL compromise recovery
Consider the situation where you are running with drives A,B,C,D and parity P, and you aren't using the "proprietary recycle bin feature" (the bit that hooks filesystem calls to keep everything in sync). If you delete file A1, you just compromised your ability to rebuild files B1,C1 & D1 if you have a drive failure before the next snapshot. And that's the best case. The bits that A1 was paritied against could be scattered across files B1-Bn, C1-Cn, D1-Dn. If A1 was a large file, like a movie, the odds are high that you just compromised the parity protection of a significant portion of your entire array. If you lose a drive before the next snapshot, it will take you longer to sift through what survived and what didn't than it will to rerip from original discs.
Granted, most people (I assume) don't delete things from their media collection until they start running out of space, and the data is relatively static. Let's say you are at only at 75% utilization with a 4+1 Flexraid setup, and therefore aren't concerned being forced into turning on drive pooling because of the deletion problem. If you scrapped Flexraid and reclaimed drive P, that drops you to 60% utilization (.75*4/5). Using the empty space for simple data duplication leaves 6.6% (2/5-1/(.75*4)) of your data unprotected during a single drive-loss AND you get to choose which data isn't being protected, such as low-demand rips. Compare that to the previous scenario, which could wipe out a fourth of it.
Once your utilization goes up, snapshot parity without pooling gets better, but once you get above 85%, you are going to want pooling anyways. That's a pretty damn small utilization window. Even if it makes sense when you design the system, it doesn't take much growth for it to become the wrong answer.