My clearing the foreign config on the "new" disk all you are doing is erasing the COD on that disk and making it available as a replacement disk - after which the array should start rebuilding onto the "new" disk. What I suspect has happened here is that your "new" disk isn't a completely "clean" disk (did you reuse it from another server perhaps?) and therefore has a COD on it from a previous life - when the controller detects the new disk, it spots that the COD isn't matching everything else in its little world and flags this up, rather than just recklessly overwriting what may be on the disk. Similarly, if a disk fails and is replaced with a (completely new and clean) disk, then the new disk can be imported into the array with information from the other CODs
The idea of this is that if the controller fails and is replaced, the configuration can be restored from the CODs without having to manually reconfigure the RAID controller and arrays When the controller boots, it read the NVRAM configuration (if the controller has NVRAM) and also the COD from all connected disks if there is an inconsistency anywhere, it reports a foreign config. Foreign Config comes about as a result of the RAID configuration being held (potentially, depending on the controller) in NVRAM on the controller and also on every disk in the array(s)Įach connected disk has a COD (configuration on Disk) which takes up a small area on the start of the disk
0 kommentar(er)
