mjhjmtu

I'm doing the following test with Debian 9 under Hyper-V: I have two (virtual) disks, each with one partition, and /dev/md0 defined as RAID1 of /dev/sda1 and /dev/sdb1. The root EXT4 file system defined on md0 works well.

Then I reboot the machine removing the sdb disk, by deleting the virtual hardware. Everything works fine, I get an email saying that the array is now clean but degraded:

md0 : active raid1 sda1[0]
 4877312 blocks super 1.2 [2/1] [U_]

Ok, as expected. I re-attach sdb, creating a new virtual disk using the same disk file and reboot the machine but the system doesn't seem to re-detect the disk. Nothing is changed, the array has still 1 drive and is in clean, degraded state. mdadm --detail /dev/md0 still reports the disk as removed.

I expected the disk to be re-detected, re-attached and re-sync automatically the next boot, since the uuid and disk name match.

I re-added the disk manually, mdadm --manage /dev/md0 --add /dev/sdb1, the system syncs it and the array goes back to clean.

Is this the way the system is supposed to work?

PS: I have a significant number of mdadm: Found some drive for an array that is already active messages at boot. mdadm: giving up.

If a RAID disk just vanishes suddenly (as far as the OS is concerned), causing the RAID array to become degraded, and then comes back, is it because the system administrator intentionally pulled the disk and then reinserted it? Or perhaps because there is an intermittent connection somewhere, perhaps a bad cable or a loose connection?

If the system had a way of knowing that the removal and restoration was intentional, it could automatically pick it up. But a software RAID has no such knowledge, so it assumes the worst and acts as if the disk or its connection has become unreliable for some reason, until told otherwise.

A hardware RAID controller with hot-pluggable disks may have extra circuitry to detect when a disk in a particular slot has been physically removed and replaced, and may work with an extra assumption that all the disks in slots associated with that RAID controller are always supposed to be RAID disks.

So when a disk vanishes and a hot-plug monitor circuit indicates the disk was physically removed, the controller can check any disk subsequently plugged into that same slot for its own type of RAID metadata. If there is no metadata present, it's presumably a new disk fresh from the factory, and can be freely overwritten as soon as the hot-plug monitor circuit indicates the disk is fully slotted in. Likewise, if the metadata indicates it's the same disk being re-inserted, the RAID set can be automatically recovered.

If the metadata is present and indicates that the disk used to belong to a different RAID set, the system administrator might be setting up to rescue data from a different server that uses the same type of RAID controller, and so it will be best to wait for further instructions: the administrator will decide whether to overwrite the disk or to import its RAID set as another RAID volume with its existing data.

But if a disk vanishes while the hot-plug monitor circuit indicates it's still physically present, the hardware RAID controller will have a very good case for declaring it faulty, even if it later re-appears on its own.

(An important side lesson: If you are moving hardware RAID disks from a failed server to another similar server to salvage the failed server's data, make sure the recipient server does not have any of its own RAID sets in a degraded state before plugging in the disk containing the only copy of some critical data. )