Hi Luigi, On 9/8/22 10:51, Luigi Fabio wrote:
Upon reboot, the arrays would not reassemble - this is expected, because 4/12 drives were marked faulty. So I re--created the array using the same parameters as were used back when the array was built.
Oh, No!
Unfortunately, I had a moment of stupid and didn't specify metadata 0.90 in the re--create, so it was recreated with metadata 1.2... which writes its data block at the beginning of the components, not at the end. I noticed it, restopped the array and recreated with the correct 0.90, but the damage was done: the 256 byte + 12 * 20 header was written at the beginning of each of the 12 components.
No, the moment of stupid was that you re-created the array. Simultaneous multi-drive failures that stop an array are easily fixed with --assemble --force. Too late for that now.
It is absurdly easy to screw up device order when re-creating, and if you didn't specify every allocation and layout detail, the changes in defaults over the years would also screw up your data. And finally, omitting --assume-clean would cause all of your parity to be recalculated immediately, with catastrophic results if any order or allocation attributes are wrong.
):
Where do I go from here? I have had similar issues in the past, all the way back to the early 00s, and I had a near-100% success rate by re--creating the arrays. What is different this time? Or, is nothing different and is the problem just in the checksumming?
No, you just got lucky in the past. Probably by using mdadm versions that hadn't been updated.
You'll need to show us every command you tried from your history, and full details of all drives/partitions involved.
But I'll be brutally honest: your data is likely toast. Phil
