CephCXI · Manager RecoveryManager Recovery
CephFS through a manager outage
What you'll learn
- Explain why MDS failover is monitor-driven
- Identify what a manager outage removes from CephFS
- Contrast the manager and MDS standby models
- Inspect filesystem state without a manager
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
Why this matters in production
An MDS fails over correctly with every manager in the cluster dead, and at the same time no new CephFS volume can be provisioned — so the filesystem is simultaneously fine and unusable, depending on who is asking.
MDS failover does not involve the manager
The MDSMap lives in the monitors. The monitors track MDS beacons, declare a rank laggy when the grace period lapses, and promote a standby. No part of that path touches a manager.
ceph config get mds mds_beacon_grace
ceph config get mon mon_mgr_beacon_grace
ceph mds stat
ceph fs dump | head -25
cephfs:1 {0=ceph-b=up:active} 2 up:standby
What a manager outage removes from CephFS
| Capability | Module | Consequence |
|---|---|---|
ceph fs status | status | no summary view |
ceph fs top, ceph fs perf stats | stats | no client or MDS metrics |
ceph fs volume, subvolume, subvolumegroup | volumes | CSI provisioning stalls |
ceph fs snap-schedule ... | snap_schedule | scheduled snapshots stop firing |
ceph nfs export ... | nfs | NFS exports cannot be changed |
| Filesystem pages in the dashboard | dashboard | no UI |
| MDS metrics in prometheus | prometheus | a gap in the series |
Existing mounts read and write throughout. New PersistentVolumeClaims
stay Pending, and nothing on the Ceph side reports an error, because the
command was never routed anywhere.
Two standby models
| Manager | MDS | |
|---|---|---|
| Standby holds state | none | standby-replay tails the journal |
| Promotion decided by | monitors | monitors |
| Grace before promotion | mon_mgr_beacon_grace | mds_beacon_grace |
| Time to serving | promotion plus module load | replay, resolve, reconnect, rejoin |
| Client impact meanwhile | none to I/O | metadata operations block |
| Warm standby available | no | yes, allow_standby_replay |
| Cost of the standby | an idle process | a process tailing the journal with cache |
ceph fs set cephfs allow_standby_replay true
ceph fs get cephfs | grep -E 'max_mds|standby'
Inspecting the filesystem without a manager
ceph fs dump --format json | python3 -c '
import sys,json
d = json.load(sys.stdin)
for fs in d["filesystems"]:
m = fs["mdsmap"]
print("fs %-12s max_mds=%s up=%d" % (m["fs_name"], m["max_mds"], len(m["up"])))
for gid, i in m["info"].items():
print(" rank %-3s %-24s %s" % (i["rank"], i["name"], i["state"]))
print("standbys:", [s["name"] for s in d.get("standbys", [])])'
ceph mds stat
ceph fs ls
ceph tell mds.0 status
ceph tell mds.0 session ls | python3 -c '
import sys,json; print("sessions:", len(json.load(sys.stdin)))'
ceph health detail
Quiz
Knowledge check · 4 questions
Q1. What happens to CephFS when every manager in the cluster is down?
Q2. A total manager outage prevents an MDS from failing over to a standby.
Q3. Diagnose CephFS PersistentVolumeClaims stuck in Pending.
A Kubernetes cluster reports CephFS PVCs Pending for two hours. Existing CephFS mounts read and write normally, and the Ceph cluster was last checked as HEALTH_OK by a dashboard that is now unreachable.
Q4. Why can an MDS standby be warm while a manager standby cannot?
Passing score: 75%. Answers are checked in this browser.
Production discipline
When CephFS provisioning stalls but existing mounts are healthy, check manager state before filesystem state — every symptom points at CephFS and the cause is usually a manager. After any manager outage, audit whether CephFS snapshot schedules and RBD mirror schedules fired; nothing records the ones that did not.
Cross-course references
- Kubernetes: a CSI provisioner failure leaves running pods serving and new claims Pending
- Linux: a control-plane outage is invisible on the data path and total on the provisioning path