Thanks Phil. --assemble --force is all it took - glad I held off. That was my first instinct to try, but I was worried it would still leave the drives as spare AND somehow mess up the metadata enough that it wouldn't be recoverable, so I was afraid to touch it until someone could confirm the approach. Seems like a silly reason to have the array down for multiple days, but better safe than sorry with that much data. Thanks again to both you and Jim! Mike On Sun, Sep 18, 2011 at 9:23 AM, Phil Turmel <philip@xxxxxxxxxx> wrote: > Hi Mike, > > On 09/17/2011 11:59 PM, Mike Hartman wrote: >> On Sat, Sep 17, 2011 at 11:07 PM, Mike Hartman >> <mike@xxxxxxxxxxxxxxxxxxxx> wrote: >>> Yikes. That's a pretty terrifying prospect. > > *Don't do it!* > > "mdadm --create" in these situations is an absolute last resort. > > First, try --assemble --force. > > If needed, check the archives for the environment variable setting that'll temporarily allow mdadm to ignore the event counts for more --assemble and --assemble --force tries. > > (I can't remember the variable name off the top of my head.) > > Only if all of the above fails do you fall back to "--create", and every single "--create" attempt *must* include "--assume-clean", or your data is in grave danger. > > Based on the output of the one full mdadm -E report, your array was created with a recent version mdadm, so you shouldn't have trouble with data offsets. Please post the full "mdadm -E" report for each drive if you want help putting together a --create command. > > I'd also like to see the output of lsdrv[1], so there's a good record of drive serial numbers vs. device names. > > HTH, > > Phil > > [1] http://github.com/pturmel/lsdrv > > > -- 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
