unraid Help me understand unRAID vs "traditional" RAID

[myplaybox]

Idk if that belongs here, but I have a question about unRAID and how it handles redundancy.

 

I understand how RAID 5 works, the other disks can combine their data to form a new disk if one fails. But that's striped across the drives.

I also understand that unRAID is fundamentally different and does not stripe data (fills disks individually) but I wanna know how some scenarios would work out.

Imagine a setup like this on unRAID:

 

The parity disk can be reconstructed since the data is still on the other disks.

Disk A, B and C can easily fit on the parity disk. But what if disk D fails? Where is the parity for that one?

[ChrisLoudon]

8 minutes ago, myplaybox said:

The parity disk can be reconstructed since the data is still on the other disks.

Disk A, B and C can easily fit on the parity disk. But what if disk D fails? Where is the parity for that one?

Interesting question!

 

TBH, I'm not sure HOW Unraid deals with Parity but as I have an Unraid setup, I do know that regardless of how many drives you have in the main storage pool, if you have 1 Parity disk, 1 storage drive can fail and if you have 2 parity disks (I think that's the max), you can have 2 storage drives fail.

 

The 2 other great things about Unraid is when a storage drive fails, ONLY the data that was stored on that disk is unavailable until the drive is replaced and the parity data used to reconstruct the missing data.

 

Storage pool drives can also be mixed and matched in size so no need to use identical drives. The only stipulation is that the parity drive(s) need to be the same size or larger than the largest disk in the storage pool.

 

My array had an 8TB + 6TB for double parity then a storage pool of a 4TB + 4TB + 4TB + 2TB + 1TB.

 

As i was running low on space I decided I didn't need double parity so I moved the 6TB Parity disk to the storage pool.

[ChrisLoudon]

Forgot to mention, as data isn't striped, there is no speed boosts so a fast ssd with a good chunk of DRAM cache is very handy as a cache disk.

 

Just be mindful of what SSD you get.

 

I was using a 4TB Samsung QVO drive and wasn't aware that write speeds tank to <20MBs on large files as the DRAM cache would run out quickly.

[myplaybox]

Yeah that's a big reason I chose unRAID too. I often buy used drives because I'm saving a lot of money and mixing and matching drives is really helpful. Also I already use a cache drive, some Samsung SSD I had lying around. Speed is not really my concern.

I am building my system at the moment, but I am scared because of that question.

 

You can also make an array of four 3 TB drives with one being for redundancy. (3x 3 TB array + 1x 3 TB redundancy)

But how is that redundant if it doesn't stripe the data?

I genuenly don't understand how it works tbh.

[Kilrah]

https://docs.unraid.net/unraid-os/manual/what-is-unraid/#parity-protected-array

 

Basically bit 1 of the parity drive is the XOR of a more or less long word made by concatenating bit 1 of each drive. Should a bit be lost (because its drive is gone) XORing everything that's left returns what it should be.

[myplaybox]

Thanks, I understand now. Took me a while, but I see now what you meant by XOR. That's why drives have to be zeroed out before inserting into the array.

For anyone still not sure, I found a great video which expleins it quite well too.

 

[manikyath]

the thought process between RAID5/6 and what unraid does is fundamentally the same, but the way it is achieved differs.

 

in a RAID5/6 array everything is written "across" all drives, splitting at a bitwise level just like RAID1 does, for example if you have a RAID5 with 3 disks, half of the data is on one disk, half the data is on another, and the third contains the parity data. raid6 just adds an additional slice of parity data.

 

unraid stores files on 'data' disks in their entirety, the parity disk (or disks) then store the same style of bitwise parity calculation of the data on these data disks.

 

the key difference in the parity calculation is that RAID5/6 splits data and parity across all drives, and unraid dedicated specific disks to parity operation.

 

essentially, the data on a raid5 array looks like this:

and an unraid array would essentially contain A-D1 on disk1, A-D2, on disk2, A-D3 on disk3, and A-D parity on the parity drive.

 

essentially if we ignore the way the data itself is stored (striping vs whole files) and the way the parity is stored (dedicated parity drive vs spread out) they both do the exact same thing.

 

for parity calculation sake each drive is just a big row of bits: one or zero.

 

you then put all of those rows side by side, and your parity is also just a big row of bits, each one is the XOR result of the other bits on that place in the row. the unraid page @Kilrah linked does a good job at explaining this process.

 

the difference in methodology that unraid uses compared to traditional RAID5/6 has one very interesting benefit for home users: as long as your parity drive is equal in size to the biggest drive in the array, you can use any odd mix of drives you like and the parity mechanism isnt affected. this is displayed in before mentioned unraid page by having different length bit rows in the example.

 

on another note; this is why on unraid's webinterface on the main page all disks have a "disk usage" bar, except for the parity drives, because they are essentially "always full"; they contain a full array of XOR data, no matter how much or little is stored on the rest of the array, or no matter how big or small the other drives are.