What about three-way mirror and dual-parity?

[garyvoth]

Hello. I have been following this work in your post on Reddit. Thank you for doing all of this research.

That post has been locked and so I could not comment there. But I wanted to call your attention to an old discussion I found on Ars Technica for how three-way mirror layouts work with Storage Spaces. See the comment by PreventRage from Microsoft here:

https://arstechnica.com/civis/threads/storage-spaces-3-way-mirror-requires-5-drives.1203237/

According to this, in a standard mirror or single parity layout, Storage Spaces may not really have an effective way of determining which copy of the data is valid when corruption occurs. It is only when adding a second layer of redundancy via a three-way mirror or dual-parity layout that it has an effective quorum of disks to "vote" on what data is correct.

This made me wonder if the seeming random behavior your script has experienced with ReFS is down to this underlying limitation with Storage Spaces. Perhaps the data corruption would be effectively corrected if the ReFS volume was built on a virtual disk having a second layer of redundancy?

Edit: although in thinking about this further, it seems that ReFS should have all the information it needs to determine correctness since it has its own checksums when integrity streams are enabled. Still, it would be an interesting test to run. I'd welcome your thoughts anyway.

[Borgquite]

@garyvoth Indeed. Have a look at line 12 of the script, where I already linked to that forum post :) A 2-way mirror requires at least 3 disks to recover from every type of metadata correction. That is why the script defaults to testing a 3-disk, 2-way non-parity mirror by default, and that is the basis on which I do all of my personal tests.

It is possible to update the script to test a 5-disk, 3-way mirror in the script (update $numdrives, and $newvolumearguments as documented) but my reading of PreventRage was that a 3-disk, 2-way mirror should still protect data, as a quorum does exist - it's just the operating system allows you to create a 2-disk, 2-way mirror if you want to because that's a 'consumer' feature (but not a 3/4-disk, 3-way mirror because that's 'enterprise'). I'll also say that I have tested 5-disk, 3-way mirrors (and most other combinations) in previous versions and it didn't have any impact on the success or otherwise of the tests.

P.S. to your 'edit' - yes, you are right - ReFS still has all the information it needs, and we're not corrupting the metadata in any way. I really don't think there's any excuse when you've failed a checksum on one disk, to not check the checksum on the 'other' disk before failing to repair, or even overwriting the 'known good' data with dodgy data before checking the checksum of it (yes, that's actual ReFS behaviour with integrity streams enabled sometimes).