NonRAID – fork of unRAID array kernel module

What I mean is that unraid, zfs and md all allow you to run a scrub over your raid to check for bit rot. That might happen for all kinds of issues, including cosmic rays just flipping bits on the drive platter. The issue is that unraid and md can't do much if they detect a block/stripe where the parity doesn't match the data (because it doesn't know which of the drives suffered a bit flip). Zfs on the other hand can repair the data in that scenario because it keeps checksums.

Now a fairly common scenario is to use unRaid with zfs as the file system for each partition, having Y independent zfs file systems. In that case in theory the information to repair blocks exists: a zfs scrub will tell you which blocks are bad, and you could repair those from parity. And a unraid parity check will do the same for the parity drives. But there is no system to repair single blocks. You either have to dig in and do it yourself or just resilver the whole disk

If you have a redundant dataset (#1 reason to use ZFS replication) then you can repair a ZFS dataset.

This is the biggie for me, not for electricity but for noise.

My /archive share is two big-ass SAS drives that were cheap. They are also LOUD.

But since I don't poke around the archive much, they sleep most of the time.

> The server basically maintains itself, I only go in every so often and bump the docker containers at this point. But I also know that I can add another disk to it in a about 10 minutes and a couple hundred bucks.

Yes. UnRAID rightfully gets a lot of attention for its flexibility in upgrading with disks of any size (which feels like magic), but for me its current >100-day uptime while maintaining a UnRAID array, three VMs, and a few other services is just as important. The only maintenance I do is occasionally look at notifications, and every month (if that often) upgrade plugins/Docker containers with new versions.

I think that's mainly it. It does give you some peace of mind that you are never in an "unprotected until next snapshot" state. But if you don't care, then there isn't much else that I noticed.

Hence why this is for home users that store media. ZFS is for the enterprise where you have people to babysit storage solutions.

> 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

You want your drives to fail at different times! Which means you want your load to be unbalanced, from a reliability standpoint. If you put the same load on every drive (like in a traditional RAID5/6) then the drives are likely to fail at around the same time. Especially if you don't go out of your way to get drives from different manufacturing batches. But if you misbalance the amount of work the drives get they accumulate wear and tear at different rates and spend different amounts of time in idle, leading them to fail at wildly different times, giving you ample time to rebuild the raid.

I'd still recommend anyone to have two parity drives (which unraid does support)

The wear on the parity drive is the same regardless of raid technology you choose, unraid just lets you have mismatched data drives. In fact you could argue that unraid is healthier for the drives since a write doesn't trigger a write on all drives, just 2. The situation you described is true for any raid system.

Depends. If you use a cache like they recommend you’d only get parity writes when it runs its mover command. Definitely adds a lot of wear but so far i haven’t had any parity issues with two parity drives protecting 28 drives.

No, because you have a cache pool and calculate the parity changes on a schedule, or when specific conditions are met, e.g., remaining available storage on the cache pool.

The cache pool is recommended to be mirrored for this reason (not many people see why I find this to be amusing).

Without error coding only a perfect channel can give lossless performance. But with error coding even a fairly lossy channel can give performance that is arbitrarily close to lossless, depending only on how much capacity you're willing to waste.

As the number of blocks on our storage devices grows their the probability that there is at least one with an error goes up. Even with raid5 the probability that there are two errors in one stripe unit at the same time can become non-negligible.

Worse, for raid5/6 normally the system is defendant on the device detecting corruption. When it doesn't, the raid will not only not fix but potentially propagate the corruption to other data. (I understand that ZFS at least can use its internal checksums to handle this case).

unraid is nonsense for silly people(50year old managers).