CephXCV · Maintenance FlagsMaintenance Flags
The scrub suppression flags
What you'll learn
- Distinguish noscrub from nodeep-scrub
- Understand the resumption behaviour
- Quantify the coverage cost
- Use per-pool alternatives
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
Scrub suppression is the most commonly left-set flag because nothing visible happens while it is on.
The two flags
ceph osd set noscrub
ceph osd set nodeep-scrub
ceph osd dump | grep flags
| Flag | Stops |
|---|---|
noscrub | new shallow scrubs from being scheduled |
nodeep-scrub | new deep scrubs from being scheduled |
Neither stops scrubs already in progress.
A deep scrub of a large PG continues after the flag is set.
ceph pg dump pgs | grep -c scrubbing
Waiting for the in-progress scrubs to drain is what makes the suppression effective, and measuring immediately after setting the flag shows no change.
Resumption behaviour
While suppressed, last_scrub_stamp does not advance while time does.
Every PG's overdue margin grows together.
On resumption, all become eligible simultaneously.
Many exceed max_interval, which forces them past the load and time checks.
ceph pg dump pgs 2>/dev/null | awk 'NR>1 {print $23}' | sort | head -3
ceph health detail | grep NOT_DEEP_SCRUBBED
# resume gradually after a long suppression
ceph config set osd osd_max_scrubs 1
ceph osd unset nodeep-scrub
Lowering the concurrency before resuming spreads the burst.
The coverage cost
Deep scrub is the only verification of data that is not read.
Suppressing it for a month means a month of unverified cold data.
Corruption arising during that period is undetected until it resumes.
# how overdue is the oldest?
ceph pg dump pgs 2>/dev/null | awk 'NR>1 {print $23}' | sort | head -1
| Suppression duration | Coverage cost |
|---|---|
| Hours | negligible |
| Days | acceptable if deliberate |
| Weeks | a real gap; document it |
| Months | the check has effectively been removed |
Per-pool alternatives
ceph osd pool set scratch noscrub true
ceph osd pool set scratch nodeep-scrub true
ceph osd pool get scratch nodeep-scrub
A per-pool flag expresses the actual intent — this pool does not need
scrubbing — without removing the check from every other pool.
# and the tuning alternatives, which reduce load without removing coverage
ceph config set osd osd_scrub_sleep 0.1
ceph config set osd osd_deep_scrub_interval 1209600
ceph config set osd osd_scrub_begin_hour 22
ceph config set osd osd_scrub_end_hour 6
Quiz
Knowledge check · 4 questions
Q1. Why do suppressed scrubs resume as a burst?
Q2. Setting `nodeep-scrub` immediately stops all deep scrub activity.
Q3. Reduce scrub load on a busy cluster.
Deep scrub load is affecting client latency. A team proposes setting nodeep-scrub until the next hardware refresh, several months away.
Q4. What should be done before clearing a long-standing scrub suppression?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Extend the deep scrub interval and confine scrubs to a window rather
than suppressing them — the load reduction is comparable and the coverage
cost is bounded and measurable. Lower osd_max_scrubs before clearing a
long-standing suppression, since every PG becomes eligible at once.
Cross-course references
- Kubernetes: disabling a periodic check because it is noisy removes what it verified
- Linux: deferring integrity checks indefinitely is functionally disabling them