On 11/30/2017 04:39 PM, Duane wrote:
> I need to tie off this thread.
>
> I got my data. I ended up manually (scriptly) merging all the strips.
>
> On later test RAID5 arrays, I removed all the devices. Then I recorded
> the configuration of the array from the metadata in the devices. I
> cleared the superblocks on the devices and then recreated the array. Of
> importance were level, chunk size, and device order. Data offset and
> layout were the default so I didn't specify them. The data area was not
> changed and, with the same configuration as the last array, was in a
> sane format.
Well done. Based on your OP, this was the correct solution. { Sorry I
couldn't contribute this week -- business travel. }
> ************************************************************
>
> Therefore, from my experience, the best way to recover a FAILED array is
> to recreate a new array with the same devices and settings.
No, most people don't deliberately fail a device out of an array that's
already degraded. That's an operator error that deleted the device role
information needed for any variation of --assemble.
Manual --assemble in its various forms is always preferred over
--create, and if there was any reshape in progress, the only way to succeed.
The key to successful use of --create --assume-clean is to fully
understand all of the array settings and member device order, in a
situation where the layout is unmixed. You were paranoid enough to
collect and use these details. You didn't have a reshape in progress.
You are extremely rare.
This mailing list is full of horror stories from people who ask for help
*after* using --create --assume-clean in their recovery attempts, and
who had *not* collected the necessary details. --create blows away the
prior superblocks, preventing collection of those details after the fact.
So NO, --create is rarely the "best way" to recover a failed array.
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
