Skip to main content
RunBook Academy

CephXLI · Metadata Servers (MDS)Metadata Servers (MDS)

What happens during MDS recovery

Expert⏱ ~18 minceph

What you'll learn

  • Interpret each MDS recovery state
  • Distinguish slow recovery from a stuck one
  • Diagnose a recovery that will not complete
  • Intervene appropriately when recovery stalls

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Not yet marked complete on this device.

Why this matters in production

An MDS stuck in a recovery state means the filesystem is down, and the state name is the diagnosis. Knowing what each state is waiting for turns “the MDS is stuck in rejoin” from an alarming string into a specific investigation.

The states

ceph fs status cephfs
ceph mds stat
StateDoingWaiting on
replayreading the journalmetadata pool reads
resolvereconciling cross-rank stateother ranks
reconnectaccepting client sessionsclients
rejoinrebuilding capability and cache stateclients and metadata pool
clientreplayreplaying client requestsmetadata pool
activeserving

Slow versus stuck

# sample twice, several minutes apart
ceph fs status cephfs
sleep 180
ceph fs status cephfs

# is it making progress?
ceph daemon mds.b perf dump | jq '.mds_log.replayed, .mds.inodes'

Rising counters mean progress. Unchanged counters over several minutes on a large journal mean stuck.

Diagnosing each stuck state

Stuck in replay — the MDS cannot read the journal fast enough or at all.

ceph -s                                    # is the metadata pool healthy?
ceph health detail | grep -i pg
ceph daemon mds.b perf dump | jq '.objecter'

Inactive PGs in the metadata pool stop replay entirely.

Stuck in resolve — another rank is not responding.

ceph fs status cephfs                      # which ranks are up?

All ranks must be present for resolve to complete on a multi-rank filesystem.

Stuck in reconnect — waiting for clients.

ceph daemon mds.b session ls | jq 'length'
ceph config get mds mds_reconnect_timeout

It should end at the timeout at the latest. A reconnect stage lasting far longer indicates something else.

Stuck in rejoin — usually the most common stuck state, and usually a client holding an enormous number of capabilities that must be reconciled.

ceph tell mds.b client ls | \
  jq -r '.[] | "\(.id) \(.num_caps)"' | sort -k2 -rn | head

Intervening

# evict a client blocking rejoin, accepting its buffered-write loss
SESSION_ID=12
ceph tell mds.b client evict id=${SESSION_ID}

# restart the MDS to retry from the beginning
systemctl restart ceph-mds@b

# last resort: mark the rank failed and let a standby retry
ceph mds fail b

Restarting is often the right first move for a genuinely wedged MDS, since the journal is intact and the new attempt starts clean.

Quiz

Knowledge check · 4 questions

  1. Q1. An MDS has been stuck in `rejoin` for twenty minutes. What is the most likely cause?

  2. Q2. An MDS stuck in `replay` may be blocked by inactive PGs in the metadata pool.

  3. Q3. Work a filesystem that has been down for thirty minutes.

    CephFS is unavailable. `ceph fs status` shows rank 0 in `rejoin` and has done for thirty minutes. The cluster is otherwise HEALTH_OK with all PGs active+clean.

  4. Q4. Why do capability limits protect availability and not just MDS memory?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Sample MDS counters twice before concluding a recovery is stuck; slow and stalled need different responses and look identical in a single snapshot. Set capability limits as an availability control — they bound how long a future recovery can take, which is a stronger argument than the memory one.

Cross-course references

  • Kubernetes: a controller stuck in initial sync blocks reconciliation the same way
  • Linux: a filesystem stuck in journal recovery presents the identical slow-or-stuck ambiguity