What makes this different from regular md? I'm not familiar with unRAID.
replies(2):
- It lets you throw JBODs (of ANY size) and you can create a "RAID" over them.
- The biggest drive must be a parity drive(s).
- N parity = surviving N drive failures.
- You can expand your storage pool 1 drive at a time. You need to recalculate parity for the full array.
The actual data is spread across drives. If a drive fails, you rebuild it from the parity. This is another implementation (using MergerFS + SnapRAID) https://perfectmediaserver.com/02-tech-stack/snapraid/
It's a very simple model to think of compared to something like ZFS. You can add/remove capacity AND protection as you go.
Its perf is significantly less than ZFS of course.
The cache pool is recommended to be mirrored for this reason (not many people see why I find this to be amusing).
But if the file system is corrupt then you're hosed and end up with a `lost+found`. It sounds great until it fails, and then you realize why ZFS with replication makes sense. Unraid doesn't do automatic repairs from replicated ZFS datasets yet either even if you use individual ZFS disks within your Unraid array.
> Increased perceived write speed: You will want a drive that is as fast as possible. For the fastest possible speed, you'll want an SSD
Great, now I have an SSD that is treated as a consummative and will die and need to be replaced. Oh and btw you are going to need two of them if you don't want to accidentally your data.
The alternative? Have the cache on a pair of spinning rust drives which will again be overloaded and are expected to fail earlier and need to be replaced while also having the benefit of being slow... But at least you won't have to go through a full rebuild after a cache drive failure.
Man, I am not sold on the cost savings of this approach at all... Let alone the complexity and moving parts that can fail...
Yes, Unraid can crash-and-burn in quite a lot of different ways. Ask me how I know! Why I'm all-in on ZFS now.
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
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.
I'd still recommend anyone to have two parity drives (which unraid does support)
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 negativelyGood, 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.
I started mine with a spare NUC and some portable USB drives and its grown into a beast with over 100TB spread across a high performance SSD backed ZFS pool and an unRAID array, 24 cores, running about 20 containers and a few VMs without breaking a sweat and so far (knock on wood) zero data loss.
All at a couple hundred dollars every so often over the years.
One performance trick it supports is also letting you overlay fast SSD storage over the array, which is periodically moved onto the slower underlying disk. It's transparent, so when you write to the array you can easily get several hundred MB/sec which will automatically get moved onto warm storage periodically. I have two fast SSDs RAIDed there and easily saturate the network link when writing.
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.
The ability to sleep all / individual HDDs:
* only keep awake the drives that your actually read data from * only keep awake the drive that your write data too + n parity drives
For home users, that is a TON of energy saving. And no, your "poor" HDDs are not going to suffer from spinning up a few times per day.
You can spin up/down a HDD 10x per day, for 100 years before you come even close to the manufactures (lowest) hdd limits. Let alone if you have 4+ drives and have a bit of data spreading, or combined with unraids nvme/ssd caching layer.
So unlike mdraid or zfs where its a all or nothing situation, unraid / snapraid gives you a ton of energy saving.
And i understand the US folks here do not care when they pay maybe 6 to 12 cent / kwh, but the rest of the world has electricity prices in the 30 to 50 cent / kwh, and it stacks up very fast when you are using < 1watt vs 5/7Watt per HDD/24/7...
It's only consumable if you hit the write limit. Hard drive arrays are usually not intended for tons of writes. SSDs $100 or less go up to at least 2000 terabytes written (WD Red SN700). How many hundreds of gigabytes of churn do you need per day?
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.
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.