• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

FlexRAID with various drive sizes - how safe?

Seby

n00b
Joined
Apr 1, 2013
Messages
6
Hi there,

I have just built a 10+TB storage server using 6 identical 3TB drives in a raidz2 FreeNAS setup. I can appreciate and understand that this is not a backup, but let's say the data stored has some pretty solid redundancy available.

Now, I still have a bunch of other drives lying around, and would like to use them for additional storage in a mini ITX system running FlexRAID.

This is what I have:

1x 3.0TB WD Red
2x 1.5TB WD Green
1x 2.0TB Seagate LP
1x 1.0TB WD Green
1x 500GB Seagate Barracuda

Pooled this adds up to 9.5TB of space. If I was to add parity, what size would that have to be? 3TB sounds smart, as that is the highest capacity drive in this setup... . But, how safe is that really? How does this compare regarding its protection against drive malfunctions and data integrity issues as my raidz2 setup mentioned above? Let's say one WD Green drive (1.5TB) and the 500GB drive failed at the same time - will I be able to reproduce this or am I overlooking some factor in a pooled array such as this that would cause data loss? What if the 3TB drive died?

Sorry, noob alert. Any help is greatly appreciated. :)
 
It depends how you set it up.

With FlexRAID you assign disks into DRUs (data recovery unit) and PPUs (parity protection unit).

Your PPUs have to be at least as large as your largest DRU.

For each PPU you have, you can lose one DRU.

I would set up your disks as follows:

3TB = PPU1
2TB+1TB = DRU1
1.5TB+1.5TB = DRU2
500GB = DRU3

So now imagine this like a RAID 4 and the individual disks are those PPU, and DRUs. So you can lose any 1 DRU completely since you have 1 PPU. So it's similar to RAIDz since you have 1 parity disk. Except it's a bit better because you can lose 2 disks at once if they are the right disks (in the same DRU). And also you can't lose your whole array if you lose too many disks since the array is not striped.

You can't lose disks in separate DRUs though. If you do though, then you have just lost the data on the disks that failed. Since in FlexRAID, the disk are left as normal NTFS or EXT4 disks and the actual data isn't modified by FlexRAID.
 
I'd setup the pool like how SirMaster showed it which gives you 6.5TB.

As far as your questions:
- The PPU (aka parity drive) should be the largest drive. If you had a 4TB DRU but 3TB PPU, you would have insufficient space to store all the parity due to the additional 1TB. On the flip side, 3TB DRU and 4TB PPU, everything would fit in the PPU but 1TB would be just all 0's (i.e., wasted). You can span DRU's, add a 1TB with the 3TB, to maximize space by matching DRU and PPU.
- It's pretty safe. The advantage of FlexRAID is that the data itself isn't touched so you can take out a DRU, put it in another computer, and be able to read everything. The only thing FlexRAID, in a nutshell, does is do a RAID 4 parity. If you've got 2 DRU's, and 1 PPU, the first two bits of the DRU are 0 and 1, the PPU would be 1. If you lose drive 1, FlexRAID knows "x + 1 = 1, therefore x (drive 1) should be 0."
- If two of your drives fail at the same time, you only lost the data on those drives, and no other drives lose data. If you only had 1 PPU, you would not be able to recover all the data though, but no other DRU's are effected.
 
Thank you both for these great explanations. If I get this right it would probably be much more efficient to give up on that 500GB drive and instead use another 3TB drive - this would yield 8TB at basically the same safety level as outline above for 6.5TB, right?

Would it be better to make up PPU1 out of 2x1.5TB drives? Or should DRUs ideally consist of smaller sized drives, in terms of probability of one failing and thus having to recover less data at once then?

Thank you! :)
 
Thank you both for these great explanations. If I get this right it would probably be much more efficient to give up on that 500GB drive and instead use another 3TB drive - this would yield 8TB at basically the same safety level as outline above for 6.5TB, right?

Would it be better to make up PPU1 out of 2x1.5TB drives? Or should DRUs ideally consist of smaller sized drives, in terms of probability of one failing and thus having to recover less data at once then?

Thank you! :)

If you want 8TB then yeah go for another 3TB disk.

I have thought about the option you posed of spanning the PPU rather than the DRU and it makes sense to me too.

If you used 1.5+1.5TB for the PPU, then if you lost either disk it would be trivial to just replace a disk and remake the parity. No rebuilding of actual data involved, so yeah I can't think of a reason not to do that.
 
Also keep in mind that you can add more PPU "disks" to you array (as many as you want), so as the array grows, you can add in another PPU and then another one and so on.

In terms of that 500GB drive, honestly, unless you run out of ports, and have to make a decision between the 500GB drive and a new 3TB drive, just use both! There is no harm in having a 500GB DRU. You can always change the DRU configuration at pretty much any time, because of the non-destructive nature of FlexRAID.
 
Well miniITX and many SATA ports don't go together, unless an HBA is involved.
 
I don't believe you should be spanning up your PPU, and the recommendation is typically the largest drive should be the PPU. The riskiest time is during the array rebuild, and spanning a PPU means that if either disk fails, all of the parity is gone.

As for the 500GB drive, why not just keep it in? It probably adds another 30 minutes to the parity calculation process (initializing, validate, etc...) as 1TB typically takes 1 hour. The only reason not to put it in is if you think it would fail soon which would mean a full parity update.
 
Back
Top