XFS log recovery

If XFS cannot replay its dirty log, clearing that log may mount the filesystem by discarding metadata transactions that were never completed.

XFS normally replays its transaction log during mount after an unclean shutdown. When the log is corrupt or the underlying storage is unreadable, xfs_repair may refuse to continue until the log is replayed or forcibly zeroed with -L.

Understand the symptom

The log contains metadata intent needed to finish or roll forward filesystem transactions.

WHY

What is happening

Recovery separates a replayable dirty log from corrupt log records, damaged allocation groups and unstable media. Mounting a protected copy may replay valid transactions; forced log zeroing abandons them and can leave directory, inode or free-space inconsistencies.

What you may see

Symptoms that change the recovery path.

01

Mount reports Structure needs cleaning

XFS cannot complete log replay or verify metadata.

02

xfs_repair asks for a mount first

The tool sees valuable pending changes in the dirty log.

03

Mount hangs during recovery

Storage errors or damaged log records prevent replay progress.

04

Repair suggests -L

Normal log replay is unavailable and destructive zeroing is offered.

Protect the source

Actions that can make the situation worse.

01

-L discards pending transactions

Recently changed names, allocations or files may become inconsistent.

02

Mounting writes during replay

Even a read-only request can permit filesystem recovery writes.

03

Repairing failing media adds stress

Broad scans can worsen an unstable disk or array before imaging.

Do this now

Safe steps before evaluation.

01

Stop mount and repair attempts

Do not use -L, format or create a replacement filesystem.

02

Image the full block device

Preserve XFS data, log and allocation groups before replay testing.

03

Capture stack details

Save xfs_info, UUID, kernel messages, LVM or RAID layout and command output.

04

Record the outage timeline

Document last writes, shutdown, storage alerts and prior recovery commands.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Log and geometry review

NEPFOSYS evaluates superblocks, allocation groups and whether log replay is coherent.

02

Protected replay testing

Normal mount and repair paths are tested on copies before any log-zeroing decision.

03

File validation

Recovered paths and file content are checked, with any abandoned transaction window documented.

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.

What does xfs_repair -L do?

It zeroes the log so repair can continue, discarding metadata changes that were pending there.

Can a read-only XFS mount write?

Log replay can update the filesystem during mount, so preserve the device below the filesystem first.

Should I run repair before imaging?

No when the data matters or storage is unstable; repair changes metadata and can stress failing media.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case