Linux MD problem

Mike Lovell mike at
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".
> Shane

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

# pvscan
# vgdisplay
# lvdisplay
# 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 mailing list