1

I'm working on a script to automate the process of creating a RAID array and am currently trying to figure out how to get multiple machines to recognize the array so the data can be transferred after collection.

The ultimate goal is to use a set of 5 SATA drives in a RAID 5 array, but I'm currently doing the proof of concept using 3 USB drives. I think I'm missing something in the process when stopping the RAID array on the original machine before attempting to assemble it on the other one. I copied the entries for the array from /etc/fstab and /etc/mdadm.conf from the original machine to the other one (I'm not sure if this was necessary... I'm assuming I could do it without this, just with a longer --assemble command). I had to change the /dev location because a /dev/md0 already existed on the second system, but otherwise made no other changes. However, upon assembling it on the second machine, only two of the 3 drives reported as active, and the third drive was ignored because it reported one of the other drives as failed. When using --examine, the array state information is as follows:

/dev/sdd - Array State: AA.
/dev/sde - Array State: AA.
/dev/sdf - Array State: ..A

The /dev/sdf drive is the one that is being ignored. So it looks like the first two drives report sdf as missing, but sdf thinks the other two are missing.

To stop the array on the first system, I simply unmounted the RAID location, then --failed and --removed the drives and --stopped the RAID. Is there something else I forgot to do? Or is this confusion caused by my manually copying over the RAID config info? Or something else?

1 Answer 1

2

Don't --fail the drives out, and don't --remove them. Typically the only times you manually fail drives out of an array are when the drive is actually toast, or if you need to reclaim the drive for another purpose.

You should be able to follow your procedure, but skip failing and removing the drives.

When you fail a drive out of an array, the other array members say "that drive is no longer part of this array". You can't assemble with it. You have to re-add it once the array has been assembled. That's why you see "AA." on two of the drives. It looks like the metadata gets flushed out to the drive you failed out too, as he thinks he's not in the array either. When you tried to --fail the second drive out, it would have created an array that didn't function, so it didn't write the metadata out.

So you should, on the first system:

  1. unmount the filesystem that you created on the array on the first machine.
  2. mdadm --stop the array on the first machine.
  3. Since they're USB drives, you should eject them.

Then move them to the second machine and do an mdadm --assemble /dev/mdX /dev/sdX /dev/sdY /dev/sdZ.

4
  • Ah. I thought I had to fail and remove the drives so that they wouldn't be in use by the array so I could stop the array. What do you mean by "eject"? I unmount the array, so they aren't mounted, and then I sync. The target systems are Scientific Linux (RHEL 6.4). I'll give this a try. Thanks! Apr 8, 2019 at 12:22
  • That did the trick for the most part, but when attempting to assemble it on the second system, mdadm says all the devices in the array are busy. I've run into this a number of times throughout the project... what's causing it? Apr 8, 2019 at 14:14
  • After some further investigation, I apparently had another array with a different name take over those resources even though it wasn't in my mdadm.conf file. Only found it by looking at blkid. Apr 8, 2019 at 14:18
  • If the drives are connected via USB, the old eject command is like the "Safely remove this device" drop down menu on Windows. It ensures that dirty blocks are flushed out to the device before acting like it's going away. You probably don't need that, as stopping the array should have synced the blocks, but, still... Apr 9, 2019 at 14:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .