[eddythompson80]

> Have a parity drive fail, then have another drive fail during the rebuild (a taxing process) and congrats -- your data is now eaten

That's just your drive failure tolerance. It's the same risk/capacity trade as RAIDZ1, but with less performance and more flexibility on expanding. Which is exactly what I said.

If 1 drive failure isn't acceptable for you, you wouldn't use RAIDZ1 and wouldn't use 1 parity drive.

You can use 2 parity drives for RAIDZ2-like protection.

You can use 3 drives for RAIDZ3-like protection.

You can use 4 drives, 10 drives. Add and remove as many parity/capacity as you want. Can't do that with RAID/RAIDZ easily.

You manage your own risk/reward ratio

[phoronixrly]

My issue is that due to uneven load balancing, the parity drive is going to fail more often than in a configuration with distributed parity, thus you are going to need to recalculate parity for the array more often, which is a risky and taxing operation for all drives in the array.

As hammyhavoc below noted, you can work around this by having cache, and 'by deferring the inevitable parity calculation until a later time (3:40 am server time, by default)'.

Which seems like a hell of a bodge -- both risky, and expensive -- now the unevenly balanced drive is the cache one, it is also not parity protected. So you need mirroring for it in case you don't want to lose your data, and the cache drives are still expected to fail before a drive in an evenly load-balanced array, so you're going to have to buy new ones?

Oh and btw you are still at risk of bit flips and garbage data due to cache not being checksum-protected.

[Dylan16807]

> due to uneven load balancing, the parity drive is going to fail more often than in a configuration with distributed parity

Good, it can be the canary.

> thus you are going to need to recalculate parity for the array more often, which is a risky and taxing operation for all drives in the array

This is not worth worrying about.

First off, if the risk is linear then your increased parity failure is offset by decreased other-drive failure and I don't think you'll have more rebuilds.

And even if you do get more rebuilds, it's significantly less than one per year, and one extra full-drive read per year is a negligible amount of load. If you're worried about it all hitting at once then A) you should be scrubbing more often and B) throttle the rebuild.

[eddythompson80]

You need to run frequent scrubs on the whole zfs array as well.

On unraid/snapraid you need to spin 2 drives up (one of then is always the parity)

On zfs, you are always spinnin up multiple drives too. Sure the "parity" isn't always the same drives or at least it's up to zfs to figure that out.

Nonetheless, this is all not really likely to have a significant impact. Spinning disks failure rates don't exactly correlate with their utilization[1][2]. Between SSD cache, ZFS scrubs, general usage, I don't think the parity drives are necessarily more at risk. This is anectodal, but when I ran an unRAID box for few years myself, I only had 1 failure and it was a non-parity drive.

[1] Google study from 2007 for harddrive failure rates: https://static.googleusercontent.com/media/research.google.c...

[2] "Utilization" in the paper is defined as:

       The literature generally refers to utilization metrics by employing the term duty cycle which unfortunately has no consistent and precise definition, but can be roughly characterized as the fraction of time a drive is active out of the total powered-on time. What is widely reported in the literature is that higher duty cycles affect disk drives negatively