ADR Technical Note TN-C1-001

Title: Controller Metadata Behavior, Foreign Config States, and Virtual Disk Identity Failures

Author: ADR Data Recovery — Advanced RAID & Server Recovery Services

Revision: 1.0

Program: InteliCore Logic™ — ADR’s proprietary framework that connects system behavior with human reasoning.

0. Purpose and Scope

This Technical Note documents how enterprise RAID controllers interpret, store, and protect array metadata, why they enter “foreign,” “missing virtual disk,” or “volume offline” states, and how system-level events such as firmware updates, drive-slot changes, or incomplete cache flushes lead to identity mismatches.

TN-C1 supports all controller triage pages (PERC, SmartArray, MegaRAID, Synology/QNAP ZFS metadata cases) and defines safe diagnostic actions before destructive writes can occur.

1. Metadata Primer — How Controllers Remember Arrays

  • Array Identity: Controllers store RAID geometry (order, offsets, stripe size) in both NVRAM and on-disk headers.
  • Dual Copies: Most platforms maintain one copy in controller memory and one on each member disk.
  • Epoch Counters: Drive headers contain “generation” numbers used to detect mismatched or stale members.
  • Slot Anchoring: Many controllers treat slot position as part of identity; migrating drives changes expected ordering.
  • Commit Behavior: Write-back cache commits geometry changes in batches; power loss can leave partial writes.

2. Why Controllers Flag “Foreign Configuration”

  • Mismatched epochs: One or more drives contain older/newer array metadata than others.
  • Slot movement: Drives moved between positions break the controller’s expected topology.
  • Cache vs. Disk drift: Controller NVRAM may not match the last on-disk commit after power loss.
  • Partial rebuild: Interrupted rebuilds cause divergent header updates across members.
  • Previous membership: A drive inserted from another system brings foreign headers that override assumptions.

3. “Virtual Disk Missing” / Logical Volume Not Presented

  • Header validation fails: Drive headers do not agree on RAID level, size, or sequence number.
  • NVRAM signature mismatch: Controller memory believes the array is at a different epoch.
  • Topology confusion: Members appear in unexpected slots or the controller cannot resolve order.
  • Safety lockout: Rather than risk writing new parity with unknown mapping, the controller hides the VD.
  • Implication: Data typically still exists but must be reconstructed with original member order and offsets.

4. Why Rebuilds Don’t Start Even When Drives Are Healthy

  • Parity verification required: Controller refuses to rebuild unless current members agree on array identity.
  • Unverified foreign config: A newly inserted disk has metadata that conflicts with survivors.
  • Cache policy blocks: Write-back disabled due to battery learn, forcing the controller into conservative mode.
  • Aborted rebuild residue: If a previous rebuild stopped mid-stripe, the controller will not restart.
  • Firmware protections: Modern firmware stops actions that may cause irreversible parity drift.

5. Power Loss, Cache Flush, and Coherency Failures

  • Unwritten cache: Battery-less systems may lose pending writes that updated geometry.
  • Half-committed metadata: Some disks commit header updates before others, breaking agreement.
  • NVRAM freeze: Controller retains pre-loss state while disks reflect post-loss state.
  • Post-power rebuild: Some controllers attempt automatic recovery that introduces misalignment.
  • Result: Apparent drive health but missing, offline, or foreign logical volumes.

6. Slot Order, Identity Drift & Migration Conflicts

  • Mismatch after swap: When a drive is replaced but inserted in a different physical position.
  • Chassis migration: Moving entire arrays to new hardware without verifying topology mapping.
  • Backplane anomalies: Bad expander ports cause the controller to misread slot identity.
  • Hot-swap timing: Drives arriving too early or too late cause unexpected foreign sets.
  • Outcome: Controller uncertainty results in locked arrays or hidden VDs.

7. Safe Forensic Triage — Order of Operations

  1. Clone all disks bit-for-bit and record slot → serial → WWN mappings.
  2. Export controller configuration and capture NVRAM/BBU state before clearing or importing anything.
  3. Record geometry: RAID level, member count, stripe size, parity rotation, start offsets, sector size.
  4. Audit SMART and verify each disk’s reallocation/pending/UNC status.
  5. Determine correct member order by parity consistency checks (images only).
  6. Only after identity validation: controlled re-admit or virtual RAID recreation offline.

Powered by InteliCore Logic™ — ADR’s proprietary framework that connects system behavior with human reasoning.

Pages may cite this note as: “ADR Technical Note TN-C1-001” with section anchors (e.g., /research/tn-c1-001#sec-3).

Back to Controller & Systems Triage Center