Nataraj wrote:
I've seen this kind of thing happen when the autodetection stuff misbehaves. I'm not sure why it does this or how to prevent it. Anyway, to recover, I would use something like:
mdadm --stop /dev/md125 mdadm --stop /dev/md126
If for some reason the above commands fail, check and make sure it has not automounted the file systems from md125 and md126. Hopefully this won't happen.
Then use: mdadm /dev/md0 -a /dev/sdXX To add back the drive which belongs in md0, and similar for md1. In general, it won't let you add the wrong drive, but if you want to check use: mdadm --examine /dev/sda1 | grep UUID and so forth for all your drives and find the ones with the same UUID.
When I create my Raid arrays, I always use the option --bitmap=internal. With this option set, a bitmap is used to keep track of which pages on the drive are out of date and then you only resync pages which need updating instead of recopying the whole drive when this happens. In the past I once added a bitmap to an existing raid1 array using something like this. This may not be the exact command, but I know it can be done: mdadm /dev/mdN --bitmap=internal
Adding the bitmap is very worthwhile and saves time and risk of data loss by not having to recopy the whole partition.
Nataraj _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
mdadm /dev/mdN --assemble --force could also be useful, though I would be careful here. To use this, you would have to stop all of the arrays and then reassemble. You could also specify the specific drives. If you don't have a backup, you might want to backup the single drives that are properly mounted from md0 and md1. Data loss is always a possibility with these type of manipulations, though I have successfully recovered from things like this without losing any data. In fact I pull drives out of a raid array and add new drives in daily to sync them and send the second drive off site as a backup.
Nataraj