BTW, don't I need to use the --assume-clean option in the create operation to have this work right?
Thanks,
Mike
----- Original Message ----
From: NeilBrown <neilb@xxxxxxx>
To: Mike Myers <mikesm559@xxxxxxxxx>
Cc: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>; linux-raid@xxxxxxxxxxxxxxx; john lists <john4lists@xxxxxxxxx>
Sent: Monday, January 5, 2009 2:53:43 PM
Subject: Re: Need urgent help in fixing raid5 array
On Tue, January 6, 2009 9:22 am, Mike Myers wrote:
> Thanks! I see what you are doing here. So since none of these commands
> actually change the underlying data, if I get the order right. the array
> will come up and the LVM superblock will be visible, and then I can try
> and bring the filesystem online? If I get the order wrong, I can just try
> it again with another combination. Do I have that right?
Exactly, yes.
>
> I should probably print out all the existing metadata and save it since
> the data will be wiped out by the create.
Certainly a good idea.
>
> How could the drives get the bad metadata on them> I've played with
> software raid for about 4 years and have seen seen something this strange.
I really cannot think how they could get the particular bad metadata that
they did. "mdadm --add" will change the metadata, but only to make the
device appear to be a spare, which isn't the case here.
"mdadm --assemble --force" can re-write the metadata, but again I cannot
imagine it making the particular change that has been made. Maybe there
is a bug in there somewhere.
NeilBrown
--
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
