Pausing scrub

Why this matters in production

Pausing scrub is sometimes correct and is very easy to leave paused. The flags produce a health warning specifically because forgetting them is the common failure.

The flags

ceph osd set noscrub
ceph osd set nodeep-scrub
ceph osd dump | grep flags

Note what these do not do: ceph osd pause is a different flag entirely — it stops all client I/O and is not a scrub control.

ceph osd set pause      # stops client I/O, not scrubbing — not what you want

Per-pool control

ceph osd pool set scratch noscrub true
ceph osd pool set scratch nodeep-scrub true
ceph osd pool get scratch noscrub

Per-pool flags are almost always the better choice: they express the actual intent — this pool does not need scrubbing right now — without removing the check from every other pool.

When pausing is justified

The distinction is between a bounded pause with a resume condition and an open-ended one, which is disabling by another name.

Resuming reliably

ceph osd unset noscrub
ceph osd unset nodeep-scrub
ceph osd dump | grep flags
ceph health detail | grep -i OSDMAP_FLAGS

The habit that works is attaching the resume to a condition rather than to a memory:

# resume when the recovery finishes
while ! ceph health detail | grep -q HEALTH_OK; do sleep 300; done
ceph osd unset nodeep-scrub

After a long pause, expect a burst as overdue PGs become eligible:

ceph health detail | grep NOT_DEEP_SCRUBBED

Re-enabling gradually — per pool, or by widening the window — spreads that burst.

Quiz

Production discipline

Use per-pool noscrub and nodeep-scrub rather than cluster-wide flags where the intent is pool-specific. Attach every pause to a resume condition — ideally a scripted one — and re-enable gradually after a long pause, since every PG becomes eligible simultaneously.

Cross-course references

• Kubernetes: silenced alerts without an expiry become permanently disabled monitoring
• Linux: disabling a periodic integrity job is the same trade in a different system