Dennis HilkLinux Fix LabDE

Storage & Filesystems

XFS shuts down after metadata or log I/O errors

Distinguish an XFS protective shutdown from a normal unmount, preserve the log, and choose recovery based on device stability and offline evidence.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • I/O returns errors while XFS says Shutting down filesystem.
  • The mount remains listed but ordinary operations stop working.

Relevant environment

XFS data or root filesystems, including those on LVM or multi-device storage stacks.

Recognizable messages (synthetic examples)
XFS (dm-0): Log I/O Error (0x2) detected at xlog_ioend_work. Shutting down filesystem.

The earlier device error matters; do not discard the log just to make mounting proceed.

XFS (sdb1): Corruption of on-disk metadata (0x8) detected at xfs_buf_verifier_error. Shutting down filesystem.

Preserve data and investigate storage or memory evidence before offline recovery.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • XFS can shut down to prevent further changes after log I/O failure, metadata corruption or device removal.
  • A userspace-forced shutdown is possible and must be distinguished from an unsolicited error by preceding messages.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read XFS and backing-device events; journal permissions may be required. Keep messages preceding shutdown.

journalctl -k -b --no-pager -n 400

Interpret the result: Log I/O Error or metadata corruption explains protective shutdown, while User initiated shutdown received indicates a requested action.

Check 2

Replace /affected/path with an existing path on this XFS mount. Read the exact device or mapper source.

findmnt -T /affected/path -o TARGET,SOURCE,FSTYPE,OPTIONS

Interpret the result: A shutdown does not necessarily change the displayed rw flag. Checking the wrong underlying LVM member instead of the mapped filesystem can mislead recovery.

Evidence-guided next steps

Stabilize storage before replaying the XFS log

If logs show hardware I/O loss, stop workload and correct the failing path or rescue to a healthy device first. On stable storage, a normal mount and clean unmount can replay a dirty log before offline verification.

Precautions: Log replay changes metadata. Secure an image or backup first and do not repeatedly mount storage that continues returning errors.

Recovery / rollback: Retain the untouched image; if replay or mounting fails, stop and use the saved copy for a recovery plan.

Did this solution help you?

Share this solution#

Review offline XFS repair needs

If corruption persists after the backing device is stable, unmount XFS in recovery mode and review xfs_repair -n on the exact filesystem device. Plan actual repair only after reading its findings and preserving data.

Precautions: A dirty log can block the assessment. xfs_repair -L discards the log and can lose files; it is a last-resort recovery decision, not a routine fix.

Recovery / rollback: Repair cannot be reliably undone. Restore the preserved image or backup if necessary, and keep the failing source unchanged.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.