FlexRaid: Transparent RAID (tRAID) vs RAID over File System (RAID-F)

[sfnetwork 514]

http://www.flexraid.com/faq/

 

I've been using RAID-F for a while now but it seems like tRAID is more appropriate and better for the use of media storage (frequent adds and mods)

 

Anyone tested this?

[ebr 14910]

I've been in snapshot raid since I set it up.  I don't need real-time recovery as media files are large and don't change and one or two could be re-ripped if necessary.  So, don't want to take any associated performance hit with a real-time parity setup.

[AMenard 2]

Since I don't really need drive pooling and I'm kinda cheap I went with SnapRaid which is free and does the same thing as FlexRaid-F...

[Airbender 113]

Hi does anyone know how to install T Raid ?

It seems that they have Host package and Client package . and i am not sure which one is which so i was just wondering

 

Thanks

[sfnetwork 514]

Check their wiki, it's pretty well described.

 

http://wiki.flexraid.com/category/traid/

Edited December 8, 2013 by sfnetwork

[Airbender 113]

Check their wiki, it's pretty well described.

 

http://wiki.flexraid.com/category/traid/

Hi so are you still using Raid f or did you switch to tRaid ? just wondering

[wraslor 70]

Using Traid here.  One complaint I  have is speed, it is slow writing to the disk in stock form I'm getting 20-30 MBs per sec.  You can tweak things such as os caching, tcq, etc that speed it up a little think 33 to 35mb per sec but still pretty slow.  Reads are normal.  I hear the creator is going to be releasing an updated performance version in a week or two that should help.  Now as for advantages it only sees the disk not files so when a disk goes out you pop in a new on and rebuild much like hardware raid except that all the other disks and files are still online and accessible. No being down for 20 hours while it rebuilds!

[sfnetwork 514]

Hi so are you still using Raid f or did you switch to tRaid ? just wondering

I'm still on RAID-F

[Airbender 113]

Cool thanks

 

 

Sent from my iPhone using Tapatalk

[ebr 14910]

I'm still raid-f too.  Don't really see the advantage of an immediate parity setup for large media files that never change once written.  Any of the stuff that does actually change can easily be re-generated if need be.

[Airbender 113]

I'm still raid-f too.  Don't really see the advantage of an immediate parity setup for large media files that never change once written.  Any of the stuff that does actually change can easily be re-generated if need be.

Hi i agree

[sfnetwork 514]

Here is the issue with RAID-F.

Modifying files that aren't excluded in Flexraid create corruption in recovery if a drive fails between the mod and next update process.

So I have to configure exclusions in FlexRaid for nfos, xmls, etc... basically all file that can be modified frequently.

Delete doesn't create this issue if you enable the FlexRaid recycling bin.

Create doesn't create issue.

 

tRAID works around this issue.

Plus, From what Brahim mentioned, tRAID pooling is different and may resolve also issues (like the access denied, scan performance, etc...)

But I won't switch to tRAID (and pay for it) just to confirm this...

Edited December 9, 2013 by sfnetwork

[ebr 14910]

Define "create corruption in recovery"?  If I only lose 1 days worth of data I am okay with that. 

[sfnetwork 514]

Define "create corruption in recovery"?  If I only lose 1 days worth of data I am okay with that. 

That was my confusion in the beginning also...

I did a LOT of testing before going with FlexRaid (recovering, etc...)

 

Of course if you loose a drive and accept that data from it is gone, no problem, but what's the point of having FlexRaid except just using the pooling feature, no fault tolerance.

BUT, the way I understood it, if, in the pooling, before next update, you have let's say 200MB of data modified, loose a drive, replace it and run the recovery process for this drive, you could have 200mb of data corrupted (not just for this drive, all across the pool.

 

I'll try to find the tread in FlexRaid that I created asking for confirmations.

 

So, it is recommended to exclude those files that can be modified which is not fun (using the regexp, etc...)

[ebr 14910]

I said 1 days worth of data - not one drives worth...

 

I have not tested recovery and haven't had the occasion to have to use it yet (I can hear my drives burning up now...) so I guess we'll see what happens when I hit that bridge.

[sfnetwork 514]

Yeah, that's the scary part (and the confusion I had). the "corrupted" data after a recovery tentative won't only affect the files from the previously failed drive, it may affect files on the other drives from the pool.

[sfnetwork 514]

• Renames will NEVER compromise recovery
• Moves including moves to different drives that are part of the RAID will NEVER compromise recovery
• Deletes will compromise recovery UNLESS the operations are done through the storage pool and FlexRAID’s proprietary recycle bin feature is turned on
• Edits WILL compromise recovery
• Writing new files to your RAID will never compromise recovery, but you risk losing these new files (and only those new files) if the drive they are on fails before you have a chance to synchronize the RAID

 

1.Edits WILL compromise recovery

- If the edited data is only on the failed drive, then data will be restored on the failed drive as it was at the time of the last snapshot

- If the edited data is on other drives, recovery will be compromised and the restored drive will sustain random corruptions up to the size of the data edited on the other drives

Edited December 9, 2013 by sfnetwork

[xnappo 1593]

I don't get what you mean - how could it affect other drives in the pool?  The file don't split between the drives...

 

Now - if you mean that if you have one drive totally fail, and a second partially fail - then yes that is true - the partially failing drive may not be recoverable.

 

[EDIT] You posted at the same time as me.  Yes - if you have a failure and have 200mb of modified data on another drive, you will not be able to get a full recovery.  For me, that is acceptable for movie rips and TV.  I certainly don't keep anything actually important on it.  For actually import stuff I do a full backup.

 

xnappo

Edited December 9, 2013 by xnappo

[sfnetwork 514]

When recovering, it uses the data from the other drives along with parity drive so all drives are involved in this process. (I might really not explaining it well BTW and I'm sorry)

I learned this the hard way...   and lost A LOT OF DATA in the past just because of one drive recovery. (and I did a lot of mod just before next update (remuxing, etc...) so I really got in the worst case scenario.

When recovering the failed drive, if edits were made not only on this specific failed drive, the recovery can affect data on other drives. (that's the random part from the "the restored drive will sustain random corruptions up to the size of the data edited on the other drives")

 

If an update ran then recovery will be fine. The issue is between modify files and update. 

 

That's why I worked hard on my exclusion list... XML and NFOs can be often modified.

And force update if I did a lot of modifications on media files (not in exclusions.)

 

I may be wrong on some level too but I know that modifications between updates can affect data on the other drives (that are fine) when recovering this failed drive. That, I know...

[ebr 14910]

Well, since I don't split folders across drives I don't think I'd ever encounter the situation that would cause this corruption.

 

Plus, I'm not sure our processes constitute "editing" as we tend to write out complete files as overwrites.

[sfnetwork 514]

Well, since I don't split folders across drives I don't think I'd ever encounter the situation that would cause this corruption.

 

Plus, I'm not sure our processes constitute "editing" as we tend to write out complete files as overwrites.

Again, I don't split files either. corruptions can  affect "random" data (data that has nothing to do with the modifications in question) when recovering.

That is the scary part and the big confusion I had when I had this issue.

[xnappo 1593]

sfnetwork is right.  It is just like PAR files.  The data on drive A is PART of the recovery information for drive B.

 

Think of it as the parity drive having 4 par files, drive A has 4 rar files, drive B has 4 rar files.  If drive A fails and the drive B rar files do not match what the parity drive par files were calculated with, you are screwed.  This is how a 4GB parity drive can handle an infinite number of more 4GB drives.

 

xnappo

Edited December 9, 2013 by xnappo

[ebr 14910]

Ah, right, of course.

 

So the issue isn't one file spanning multiple drives it is if any data has changed on more than one drive.  Yes, I see this would render snapshot raid just about useless in all but the most static environments.

[xnappo 1593]

Ah, right, of course.

 

So the issue isn't one file spanning multiple drives it is if any data has changed on more than one drive.  Yes, I see this would render snapshot raid just about useless in all but the most static environments.

Well I wouldn't go that far.  MOST of the drive B data will match MOST of the parity 'PAR' files, and will recover.  It isn't like one big PAR set, it is a bunch of little ones.

 

xnappo

[sfnetwork 514]

Best scenario if possible is if you can predict a pre fail... You run one last update before.

But again, what would be the point (just clone the drive to new one if you can predict a failure)

 

To be honest, I value way more the pooling than the fault tolerance in RAID-F (and even the pooling has issues that needs to be resolved)

If one of my drives would fail right now, I'm not even sure if I would risk a recovery vs accept that my data is gone (I use "autofolderpriority" so it doesn't split across drives)

I have a batch file that list all drive content in txt just in case I need to redownload/rerip lost data.

 

This was why I was interested in the tRAID in the first place. Slower to read/write but rt sync (I think) so fault tolerance would be more "trustable". (less dough)

 

Like I said I learned the hard way and since then my trust in FlexRaid fault tolerance and recovery took a big hit...

When I lost all my data, I was hitting my head on the wall thinking "I shouldn't have tried to recover and just would have lost one drive content"... 

Edited December 9, 2013 by sfnetwork