Linux RAID metadata conflict

Different mdadm event counts can identify a stale member, but the highest number is not automatically the safest source.

Linux md RAID records array identity, role, state and event history on each member. A write-intent bitmap can narrow resync work, but stale superblocks, interrupted rebuilds or partial writes can make member counters and bitmap state disagree.

Understand the symptom

Array freshness depends on more than one counter.

WHY

What is happening

Recovery compares UUID, role, event count, update time, data offset, bitmap, reshape position, bad-block log and filesystem evidence. A newer member can contain incomplete rebuild data, while an older member may hold the last coherent stripe set.

What you may see

Symptoms that change the recovery path.

01

Members have different Events values

Some disks stopped participating before others.

02

Array assembles degraded or inactive

mdadm refuses a complete set because metadata state conflicts.

03

Resync restarts unexpectedly

Bitmap or recovery-position information no longer matches member contents.

04

Force assembly mounts corrupt data

A numerically newer but incomplete set was selected.

Protect the source

Actions that can make the situation worse.

01

--force can activate the wrong set

The array may accept writes using stale or incomplete members.

02

Resync overwrites differences

md copies one interpretation of parity or mirror state across the originals.

03

Bitmap deletion removes timeline evidence

It can hide which regions were dirty during the incident.

Do this now

Safe steps before evaluation.

01

Stop md services and writes

Prevent assembly, resync, LVM activation, mounts and application activity.

02

Examine every member

Record UUID, role, events, offsets, state, bitmap, bad blocks and reshape fields.

03

Preserve physical order

Label bays, serials, failed, spare, removed and replacement drives.

04

Image before reconstruction

Acquire unstable and conflicting members independently before virtual assembly.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Member-history analysis

NEPFOSYS correlates superblocks, counters, bitmap and incident timing across the set.

02

Virtual array testing

Candidate member combinations are assembled read-only from images.

03

Filesystem validation

The strongest array view is checked for volume, database and file consistency.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

Should I always choose the highest event count?

No. A rebuild or partial write can make a newer member less coherent than an older consistent set.

What does the write-intent bitmap do?

It tracks regions that may need resynchronization after interruption.

Is --assemble --force safe?

Only after members are preserved and their history, roles and consistency are understood.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case