Thanks Robin and Phil, I've verified that the parity information did in fact get recalculated and written to different disks, though I'm confident that I can still recover by reversing this. I expect that I could manually reconstruct the metadata and superblocks if I needed to but before I began I took a dd backup of the first 1GB of each physical disk, each partition, and the MD device, and I also have the /etc/space/*.xml files, so I expect I have enough to restore these. I'll start a new thread to ask about the best way to proceed. Thanks, Steven On Mon, Jul 13, 2015 at 11:17 PM, Phil Turmel <philip@xxxxxxxxxx> wrote: > On 07/13/2015 06:59 AM, Robin Hill wrote: > > [snip /] > > Let me elaborate on one of Robin's comments: > >> The --assume-clean option will prevent parity calculation (as it assumes >> that the parity on disk is already correct), which may be what you're >> after. It should only be used it you're absolutely certain of the data >> though, as it can lead to large-scale corruption otherwise. > > It is not enough to be certain of the order to use --create > --assume-clean on existing data. You must also be certain of superblock > type, chunk size, data offset, and layout option. > > Data loss due to unwise use of --create has a history of bad outcomes. > It destroys the previous metadata on array members, metadata that is > almost always needed to recover damaged arrays. The --create option > should *never* be used on an array with important data without first > asking for advice on this list. > > Phil -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
