Linux MD problem
mike at dev-zero.net
Wed Jul 8 11:24:26 MDT 2009
Shane Hathaway wrote:
> I would try assembling the array without sdx1:
> mdadm --assemble /dev/md0 /dev/sd[uvw]1 missing
> If that works, I would check the filesystem for errors *without
> repairing anything yet*, since I don't want to change any bits at all yet:
> e2fsck -n -f /dev/md0
> If that shows no errors, or a small number of easily repaired errors,
> then I would try to re-add sdx1:
> mdadm --manage --re-add /dev/md0 /dev/sdx1
> If that second command fails, I would use "--add" instead of "--re-add",
> causing sdx1 to be rebuilt from scratch.
> Then I would perform the real filesystem repair:
> e2fsck -p -f /dev/md0
> If the first command I gave doesn't work, I would use "dd" to copy the
> partitions to backup drives before doing anything else, then I would do
> more aggressive things like "mdadm --assemble --force --update resync".
I think I got something that works. Here is what I did.
# mdadm --assemble --force /dev/md0 --uuid=<uuid of the array>
This started md0 using u,v,w but without x since it looks like x had the
superblock that was causing problems. I don't have a filesystem directly
on top of md0. It is a pv for an LVM group. So I did
# lvchange -ay vg/lv
# fsck.ext3 -nf /dev/vg/lv
This seems to have picked up the VG and all of the LVs. The fsck of the
one LV did not return any errors. So I am assuming the array is okay.
After that, I added sdx1 back to the array with
# mdadm /dev/md0 --add /dev/sdx1
Now, in /proc/mdstat, i see the full array and it is resync'ing to sdx1.
So I think it is back to a usable state. Thanks for the help to both
Shane and Kenneth.
More information about the PLUG