Skip to main content
RunBook Academy

CephXCV · Maintenance FlagsMaintenance Flags

The scrub suppression flags

Intermediate⏱ ~16 minceph

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

Not yet marked complete on this device.

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
FlagStops
noscrubnew shallow scrubs from being scheduled
nodeep-scrubnew 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 durationCoverage cost
Hoursnegligible
Daysacceptable if deliberate
Weeksa real gap; document it
Monthsthe 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

  1. Q1. Why do suppressed scrubs resume as a burst?

  2. Q2. Setting `nodeep-scrub` immediately stops all deep scrub activity.

  3. 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.

  4. 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