In this instance - new additional xml files (note you are *not* editing any files, you are creating new ones this is a critical distinction in terms of flexraid) - you would not lose parity protection of your already existing data. You would also not 'lose' parity of the new xml files as you have not yet created any parity for them at this point.

 

OK, I posted "edit" twice now which does not mean adding new files. I edited the last post hopefully to make this clear enough.

 

It's becoming clear that you simply don't understand how flexraid works.

 

OK, I went to the Flexraid forum and the author posted an answer to NLS's post that confirmed my "conjecture" is exactly what would happen. After my xml file editing I would have badly hosed one of the other drives if it happened to fail before the parity had been updated. It's a big if, but still, it could have happened. It's not quite as rosy as Flexraid just not protecting my updated files. The Flexraid website says "However, if you edited or deleted data, only the un-synchronized portion will not be recoverable on the failed drive." which really isn't true. The editing you do on drive "A" will cause some level of corruption on the recovered drive "B".

 

I also understand that Flexraid is for "static" data but who never changes or sorts or edits or deletes some of their data?

 

Finally, I also understand that the problem only exists until parity is updated so therei is only a relatively small window of time where a failure could be very bad. As I posted before, I'm bringing it up because it could happen and anyone who's going to use Flexraid should understand it could happen. One response on the AVS forum claimed that drive "A" could be edited to your hearts desire and drive "B" could still be fully recovered at any time which just shows there is a basic lack of understanding of what Flexraid can and can't do.

 

Peter

You can verify parity at any point - I believe flexraid will inform you of any corrupted files (or at least what it assumes are corrupted files - i.e differences between a file on disk and the data it contains for the same file in parity).

 

How can it hold parity data for every individual file? If it did that then it'd be the equivalent of a mirrored system which it is not (well, it could be with enough multiple parity sets). I have not read anything about it storing say an MD5 or CRC type of checksum number either.

 

Peter

I don't understand the point of this discussion when most (if not all) of what you ask can very easily be answered if you try it.

 

Install host, you don't have to install the service, you can manually start the server part.

Drop webui somewhere (doesn't need install) or install cmd client...

Make three folders with some text files in (to make things easier) and leave a forth folder empty to hold the parity.

Create the array through webui or cmd client.

Do any tests you want with the files.

See what happens if you verify parity, if you delete something, if you edit something etc.

Uninstall what you installed, delete the four folders, yous system never knows what happened (well never the case with Windows, but you get my point). Excluding the time you need for your actual tests, install/create (for three small folders)/remove is maybe two minutes.

 

Else, there isn't much more to say.

 

OK, I went to the Flexraid forum and the author posted an answer to NLS's post that confirmed my "conjecture" is exactly what would happen. After my xml file editing I would have badly hosed one of the other drives if it happened to fail before the parity had been updated. It's a big if, but still, it could have happened. It's not quite as rosy as Flexraid just not protecting my updated files. The Flexraid website says "However, if you edited or deleted data, only the un-synchronized portion will not be recoverable on the failed drive." which really isn't true. The editing you do on drive "A" will cause some level of corruption on the recovered drive "B".

 

Perhaps I've misunderstood your point then. However, it remains that this is not a use case for flexraid - quite clearly stated on the website.

 

I also understand that Flexraid is for "static" data but who never changes or sorts or edits or deletes some of their data?

 

The many people using flexraid quite happily.

 

Finally, I also understand that the problem only exists until parity is updated so therei is only a relatively small window of time where a failure could be very bad. As I posted before, I'm bringing it up because it could happen and anyone who's going to use Flexraid should understand it could happen. One response on the AVS forum claimed that drive "A" could be edited to your hearts desire and drive "B" could still be fully recovered at any time which just shows there is a basic lack of understanding of what Flexraid can and can't do.

 

In my testing of flexraid I created three folders :

 

test1

test2

parity

 

Data was put into the two folders and then the parity generated using the parity folder.

 

I was able to completely remove the test1 and test2 folders leaving only the parity. I was then able to reconstruct *both* folders and their contents from parity.

 

I have no idea why this was possible, I don't think it should be as no files on any DRU now exist to calculate parity to return other files. Scale that up to whole drives and you have infinite parity for some reason.

 

But it did work. This would match the website claim (and then some!) in your scenario above. I havn't read the authors post you refer to and it would seem his response should be canon. However he may have misunderstood you the way I seem to have (?)

Strange this worked indeed.

 

Maybe in that test you created ONE DRU with both folders and NOT two DRU one folder each?

Because in the first case you just created a weird mirror (calling it weird as the "image" is not the files themselves, just their parity files).

 

 

Ya, that doesn't make sense. Parity type protection relies on the remaining data and the parity to recover data.

 

Say I have 2 drives of data and 1 drive of parity there's no way I could recover from the simultaneous failre of both data drives.  Say I have 2 x 1T full data drives (or folders or whatever) and create a 1T parity drive (or folder or whatever). The parity drive can not hold the same data as both data drives. If it could, then why would we use 2 data drives to store 2T of data and not use whatever method the parity drive used instead? After all, that would allow us to store twice the data in the same amount of space.

 

Say I have 10 X 1T data drives and 1 x 1T parity drive. By your logic, the 1T parity drive would hold enough data to recover all 10 data drives at the same time???

 

Oddly enough, the theory that you could recover every drive (or folder or whatever) from parity without having any of the other drives (or folders or whatever) also came up as a feature of Flexraid on the AVS Forum. This goes directly against what is listed on the Flexraid website. The Flexraid website says that if you have 5 data drives and 2 failed at the same time that you'd still have the data on the remaining 3. It says nothing about recoving both failed drives from the parity (using a single parity set).

 

I hate to say it, but I think your test method had a problem and it may have left you with a false impression of what Flexraid is capable of doing. This also shows the problem of just doing some simple tests as suggested.

 

I'd bet that Flexraid read the blocks on the hard drive which would still contain the data even though the file system had marked the files or folders as deleted.

 

Same way unRAID has to clear a drive to no break parity. Sure, a "ls" of the drive will show it is empty but there could still be random "1" bits left on the drive which would break parity.

 

Same way you can undelete a file after you accidentally remove it. It's still left on the physical media even though you don't "see" it.

 

Peter

 

Strange this worked indeed.

 

Maybe in that test you created ONE DRU with both folders and NOT two DRU one folder each?

Because in the first case you just created a weird mirror (calling it weird as the "image" is not the files themselves, just their parity files).

 

 

 

Yes - I think you're right, that would make sense.

 

Ok to appease lionelhutz I've run the following test which I believe matches his use case :

 

two drus :

 

data1

data2

 

One parity

 

parity

 

 

Each dru had some mp3s and text files copied into it. Parity was then generated.

 

md5sums of the files in data2 were generated.

 

id3 tags of all the the mp3s in data1 were changed and the text files were heavily edited to increase their size. Basically all files had some sort of data alteration performed on them.

 

data2 was then removed and a rebuild was triggered from parity.

 

data2 was rebuilt but some files were listed as being corrupt. A check of the previous md5 hashes confirmed this. Being mp'3s there was enough data there for them to be playable but at some point there will be errors in decoding I would presume.

 

So in an effort to bid a gallant retreat from this thread I'm going to sum up findings so far :

 

Lionelhutz' theory is correct (presuming I've replicated his original scenario correctly above)

 

However, I will reiterate that this is mentioned on the website and is stated as a scenario that flexraid does not fit.

 

If you continuously change your data during the day, every day, then FlexRAID™ Basic is not a fit for you.

 

and as part of the answer to the exact question originally asked, as previously posted in full :

 

However, if you edited or deleted data, only the un-synchronized portion will not be recoverable on the failed drive.

The remainder of the data will be recoverable.

So, if you edited or deleted only 1GB of data, only 1GB would not be recoverable.

 

This is quite clear - although does not go to pains to explain that the 1GB of data not recoverable will not be isolated in one nice lump and will more than likely be spread throughout any restored files.

 

So in my example above we've created a scenario that the faq explicitly says flexraid is not suitable for. We've then carried the scenario through such that we have posed the question immediately above - and the websites answer is exactly what has happened. I could go further and figure out the changes in data in bytes and then see if the unrecovered / corrupted areas of data in data2 match this size. Safe to assume they will?

 

So..lionelhutz is correct but I stand by my point that this info is on the flexraid website and isn't a secret. It's a fundamentally different mechanism from unraid with respect to *altering* existing files. This is what put me off flexraid two years ago (alongside full parity protection in real time being an option from unraid)

 

Apologies for my post earlier, NLS is clearly correct and I accidentally only created on DRU with both folders during testing - ending up with a mirror.

 

No more from me on the topic!

 

Flexraid FAQ - "FlexRAID™ Basic is suited for data that you only change a few times during the day"

 

It's kind of on the website but it doesn't make it clear that the data you lose will not necessarily be from the file you edited. I bet if you asked 20 average users of Flexraid there wouldn't be one who knows that editing a file in location "A" puts some of the data in location "B" at risk.

 

Peter