The following is the GNU All-permissive License as recommended in https://www.gnu.org/licenses/license-recommendations.en.html

Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.

Contributions are welcome. See https://savannah.gnu.org/maintenance/fsf/.

replace drive in raid1 or raid10

When replacing a drive in a RAID array, it's generally best to have as many previously active disks in the array as possible before adding a new drive. This allows bad blocks to be handled properly, so syncing a new drive into an array is less likely to fail, and to prevent data loss.

In that case, you should generally use the --replace option if the drive to be removed can remain within the array until the new disk is done syncing. (Then the replaced drive will automatically be kicked out when it's safe). An exception is when that drive is extremely slow, and slows down the entire array. Using it instead of --fail helps to avoid the rebuild failure risk that a degraded array poses. See the mdadm man page for details about the replace option.

If a drive has failed in the RAID1 or RAID10 array, you should --re-add it before trying to overwrite data with --add, unless the array has no bitmaps. (Note that --add will attempt to --re-add, but if that fails, it will overwrite the header and bitmaps, which can lead to rebuild failures later).

It's important that all of our arrays have bitmaps to avoid lost data when an array becomes degraded. If the array has no bitmaps, you might as well attempt to --add the new drive and hope that there are no read errors from the array.

Recently used at hal with these two commands:

mdadm --manage /dev/md122 --replace /dev/sdi1
mdadm --add /dev/md122 /dev/sdm1

Worse case scenario:

mdadm /dev/md0 --fail /dev/sda1
mdadm /dev/md0 --remove failed
mdadm /dev/md0 --add /dev/sdc1