Here: how to give the mirror its second disk back — remove the failed one, add a new one and wait for the rebuild.
The failed disk is taken out of the array with mdadm --remove. Only a disk marked (F) or a spare (S) can be removed: mdadm refuses a working disk (hot remove failed … Device or resource busy), so a working but suspicious disk is first marked by hand with mdadm --fail. On a server the disk is then swapped physically, and the new one is added with mdadm --add (in the Wiki).
The new disk joins as a spare, (S), and the array starts a rebuild (recovery) at once: the kernel copies the whole content of the working disk onto it. You can follow it in /proc/mdstat — the line recovery = 37.5% with an estimate finish=. The 128 MiB training disks rebuild in seconds, disks of several terabytes take hours. While the rebuild runs, the array stays degraded and the filesystem works as usual.
Replace the failed disk
Remove the failed disk /dev/loop1 from the /dev/md0 array, add the new disk /dev/loop2 in its place and look at /proc/mdstat to see how the rebuild went.
Goals · 0 of 2
- Remove the failed disk from the array not done yet
- Give the mirror its second disk back not done yet
The mirror's rebuild onto the new disk has reached 40% when the other disk, the one it copies from, fails. What happens to the array's data?
-
A rebuild copies the disk's blocks in order, not files. The new disk holds the first 40% of the blocks, and no filesystem can be put together from them.
-
There is nothing to switch to: until the rebuild ends the new disk is not a working one —
mdadm --detailcalls itspare rebuilding, and/proc/mdstatkeeps showing[2/1] [U_]. -
The new disk was the target of the rebuild: it holds no full copy yet, and there is nothing to continue from.
Until the rebuild is over, the only full copy sits on one disk, and losing it costs all the data.