← Back to Recovery methods

RAID Metadata, Member State and Foreign Configurations

A readable member disk is not the same as a current one — RAID metadata records chronology as much as geometry, and a controller calling a disk “foreign” is telling you something useful, not warning you it failed.

Metadata describes state, not just layout

Linux MD recognizes several on-disk metadata formats (0.90, 1.0, 1.1, 1.2, and external metadata families), and a superblock carries more than array structure: array UUID, member role, RAID level, chunk size, and state, alongside event and generation counters that identify which point in the array’s history a given member last participated in. A member’s user data commonly starts at a data offset rather than at LBA 0, and readable metadata never by itself guarantees the member belongs to the array’s current generation. RAID metadata is not only geometry — it is evidence about chronology and member state.

Foreign configuration is not a failure signal

Hardware controllers such as Dell’s PERC line can detect existing RAID metadata on a disk that does not match the controller’s current active configuration — after disks move between systems, a controller is replaced, or a virtual disk goes offline and later returns. “Foreign” does not mean “failed disk.” It means the controller sees valid metadata that is not synchronized with its current state. Before any import or clear action, preview the foreign configuration, record the virtual-disk state, record physical-disk state and slot positions, preserve controller logs, and establish whether every expected member is actually present.

Import or clear: different situations, different right answers

Importing a foreign configuration can be appropriate when the controller itself was replaced, the original array configuration is expected to still be intact, every expected member is present, and the whole virtual disk is offline or failed with the foreign metadata representing the array as it should be. Clearing can be the correct routine-maintenance action when only one stray disk shows as foreign, the active array remains online or degraded, and that single disk should not be imported as a competing array state. Neither action is universally safe: clearing can remove evidence, and importing can make the controller act on the wrong generation. Do not import or clear foreign metadata until the complete member state is understood.

Controller metadata is evidence, not disposable setup

HPE documents that clearing Smart Array controller configuration can remove array configurations and partition information along with it. Before any controller reset or reconfiguration, preserve logical-drive definitions, RAID level, member slots and serials, spare assignments, controller logs, and cache or battery/capacitor state — screenshots or an exported configuration cost nothing and can be the only record of how the array was actually built.

Bay order is a clue, not proof

Preserve physical bay position, but verify member role independently using serial number, WWN, controller slot, MD role, event counters, controller metadata, partition pattern, logs and data signatures. Bay order can mislead after drives are moved between bays, an expansion enclosure re-enumerates, a controller replacement renumbers devices, or an old removed disk gets reinserted.

Cache can decide the fate of the newest writes

RAID and SAN controllers frequently acknowledge a write to the host before that write is physically persisted to the member disks, so “the host believes the write committed” and “the write reached the disks” are separate facts. Write-back versus write-through mode, battery- or flash-backed cache, capacitor health, a preserved dirty cache after a crash, controller replacement, cache migration during failover, and the exact sequence of a power-loss event all affect the answer. The newest data acknowledged just before a failure may never have reached the member disks at all, even when the RAID geometry itself is perfectly recoverable.

Foreign does not mean failed

A disk a controller marks as foreign commonly carries completely valid array metadata. The risk is acting on it — importing or clearing — before the full member state across every disk is understood.

Related: Reconstructing NAS Storage Stacks · Recovering After an Interrupted RAID Rebuild · Storage Metadata Generations and Consistency · RAID Reconstruction Basics · RAID Array Failure