LVM thin-pool recovery
A thin pool separates data blocks from metadata that records virtual-to-physical mappings, snapshots and sharing. Metadata exhaustion can return I/O errors and leave both the thin pool and filesystems above it inconsistent.
Understand the symptom
Recovery identifies the matching data and metadata devices, transaction IDs, metadata spare, mapping health and snapshot relationships. LVM documents offline checking and lvconvert --repair after metadata exhaustion, but repair must be tested on protected copies because mappings may already be inconsistent.
What you may see
The pool cannot record new allocations or mapping changes.
Guests or filesystems fail because metadata operations cannot complete.
LVM detects inconsistent or unreadable thin metadata.
Shared mapping state no longer describes the thin volumes reliably.
Protect the source
Data, metadata and spare volumes have different roles.
A consistent metadata structure may still omit recent allocations.
Upper layers should not be repaired before thin mappings are stabilized.
Do this now
Stop VMs, containers, mounts and automated snapshot or backup jobs.
Save pvs, vgs, lvs with segment details, VG backups, UUIDs and transaction state.
Image physical volumes and keep thin data, metadata and spare devices together.
Avoid fsck, database repair and VM boot until a stable virtual block map exists.
NEPFOSYS process
NEPFOSYS correlates pool transaction state, metadata devices, mappings and snapshots.
Repair, backup metadata and alternate activation paths are evaluated away from production.
Recovered thin volumes are exposed read-only and guest filesystems or databases are checked in order.
A clear next step
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 reviewQuestions, answered
Mapping updates fail, which can return I/O errors and leave thin volumes or filesystems inconsistent.
Adding metadata space may stop future exhaustion but does not automatically correct mappings already damaged.
Only after preserving the pool and testing on copies because repair changes the metadata that defines every thin volume.
DFW local · Nationwide mail-in