Data Recovery and Disk Utilities Forum @R-TT

[quote=winguru post_id=15984 time=1558391645 user_id=4841]
Well, after much trial and error, it looks like I may have stumbled across the correct settings. Perhaps a combination of blind luck and getting dirty with the MBP/GPT and partition details, verifying expected LBA sectors match virtual RAID data, etc. I was able to mount the HFS+ partition without errors and examined a few test files and they look to have no artifacts, errors, or other signs of corruption.
[/quote]
How large they are? Larger than 3x(Block size)? If yes, the RAID parameters are surely OK.

[quote=winguru post_id=15984 time=1558391645 user_id=4841]
I still don't know what to make of those "not checked" blocks, but it doesn't seem to affect the actual data recovery.

[/quote]
I've just noticed that one disk is of another model. Does the number of its sectors on this disk _exactly_ match that on others? Maybe, this is the answer?

Well, after much trial and error, it looks like I may have stumbled across the correct settings. Perhaps a combination of blind luck and getting dirty with the MBP/GPT and partition details, verifying expected LBA sectors match virtual RAID data, etc. I was able to mount the HFS+ partition without errors and examined a few test files and they look to have no artifacts, errors, or other signs of corruption.

For what it's worth, here are the settings I used:
[attachment=1]RAID Configuration - Working.png[/attachment]


Here is the RAID consistency check:
[attachment=0]RAID Consistency Check - Working.png[/attachment]

I still don't know what to make of those "not checked" blocks, but it doesn't seem to affect the actual data recovery.

Thanks again for all your support, and let me know if you would like any follow up information. Now that I have a known good configuration, I can rest a bit easier :D

My understanding is that:
1. Offset is surely incorrect. Must not be 0. But this is not the source of the problem.
2. My understanding is you should look at block size.

Thanks for the heads up!

I tested the new version (8.10.173981) and found that the raid configuration looks better. I am able to delete the default 4-block sequences and create new 3-block sequences as expected. So that part looks correct now, as shown below:
[attachment=1]RAID Configuration - Version 8.10.173981.png[/attachment]


However, I am still seeing the same issue where 1/4 of the blocks show as "not checked". I have tried different variations, but all of the custom 3-block sequences seem to exhibit the same behaviour. Again, I am not sure how much to make of this, but it appears as though there is still something amiss, as shown below:
[attachment=0]RAID Consitency Check - Version 8.10.173981.png[/attachment]


As a test, when I took the last 3-block sequence and marked them all as ignore, I did not see the "not checked" blocked issue. Obviously this RAID configuration would not be appropriate, but it seems to indicate something internally may not like having 4 "3-block" sequences instead of 3 "4-block" sequences.

I will continue to investigate, and I appreciate all of your support thus far...

Thanks!!

Please test our new version.

Right now we're investigating this problem.

For what it's worth, I'll also share the code I wrote to create custom RAID-5 definitions for different parity delays. It doesn't generate the complete XML file, just the "table" and "sequences" sections that define the stripe pattern.

[url]https://repl.it/@winguru/R-Studio-Apple-RAID-5-XML-Definition-Generator[/url]

Comments and/or suggestions are welcome.

Thanks!

I have looked over the exported configuration of the custom RAID-5 configuration I made (as per your advanced RAID configuration guidance). I included my exported XML file as an attachment to my first message.

The key components of that file are as follows:
<Table>
<Block id="A1" sequence="1">XorOfData</Block>
<Block id="B1">1</Block>
<Block id="C1">2</Block>
<Block id="D1" sequence="2">XorOfData</Block>
<Block id="A2">3</Block>
<Block id="B2">4</Block>
<Block id="C2" sequence="3">XorOfData</Block>
<Block id="D2">5</Block>
<Block id="A3">6</Block>
<Block id="B3" sequence="4">XorOfData</Block>
<Block id="C3">7</Block>
<Block id="D3">8</Block>
</Table>
<Sequences>
<Sequence id="1">A1 B1 C1</Sequence>
<Sequence id="2">D1 A2 B2</Sequence>
<Sequence id="3">C2 D2 A3</Sequence>
<Sequence id="4">B3 C3 D3</Sequence>
</Sequences>

There are no 4 element sequences in that definition file. Nonetheless, when I load that file or create a new custom configuration, there are always 4 element segments that are at the beginning of the RAID sequence window, and they don't seem to be able to be removed. The number of these initial sequences is always the same number as the "number of rows".

Again, I'm not sure if that's intentional or not, but I've not been able to remove them regardless of how I've tried.

Hopefully the following GIF animation helps to demonstrate this behavior:
[attachment=0]R-Studio RAID Configuration Actions.gif[/attachment]

Thanks!

Have you tried our RAID description file? Because I see some wrong sequences on your second screenshot. There should be no 4-element sequences.

No, there were no errors or warnings about unreadable sectors.

If I pick the built-in RAID-5 Right Symmetric configuration, this is what I see for the RAID Consistency Check:

[attachment=0]RAID Consistency Check - 3.png[/attachment]

Thanks!