The take operation — where the descent begins

Why this matters in production

take decides which part of the cluster a pool can use at all. Everything the rule does afterwards happens inside that subtree, so it is the coarsest and most consequential line in a rule.

The basic form

step take default

default is the conventional root containing everything. A rule starting here can place data on any OSD the subsequent steps allow.

Restricting to a subtree

step take rack-a
step chooseleaf firstn 3 type host
step emit

This pool can only use OSDs in rack-a. Legitimate reasons:

• Physical isolation for a tenant or a workload with a compliance requirement.
• Site pinning on a multi-site cluster where a pool must stay local.
• Staged migration, pointing a pool at new hardware.

Illegitimate reasons include using it as a substitute for device classes, which is the next section.

Device classes and take

Device classes look like a property of the OSD, and they are implemented as shadow trees:

ceph osd crush rule create-replicated nvme_rule default host nvme
ceph osd crush tree --show-shadow

Ceph maintains a parallel hierarchy per class — default~nvme, default~hdd — containing only OSDs of that class with weights adjusted accordingly. The generated rule takes from the shadow root:

rule nvme_rule {
  step take default class nvme
  step chooseleaf firstn 0 type host
  step emit
}

So take ... class nvme is take default~nvme. This is why device classes require no manual tree restructuring: Ceph maintains the shadow trees automatically as OSDs are added and removed.

Checking what a rule takes

RULE_NAME=acme
POOL=rbd-vms
ceph osd crush rule dump ${RULE_NAME}
ceph osd crush rule ls
ceph osd pool get ${POOL} crush_rule

The rule dump shows the take step including any class. Verifying it per pool is worth doing after any CRUSH work, since a pool pointing at the wrong root is one of the quieter ways to end up with data somewhere unintended.

Quiz

Production discipline

Prefer device classes to hand-built parallel hierarchies — Ceph maintains the shadow trees automatically, while manual dual placement reliably produces OSDs that silently join only one tree. Treat a restricted take as a hard capacity ceiling and monitor that subtree’s utilisation specifically, since cluster-level capacity summaries will not show it. And verify crush_rule per pool after any CRUSH work, because a pool pointing at an unintended root is one of the quieter ways for data to end up in the wrong place.

Cross-course references

• Ceph: Part XVI (Device Classes) for the class mechanism in full.
• Ceph: Part LXIII (Capacity Management) for per-subtree monitoring.
• Ceph: Part XV (CRUSH Maps and Rules) for writing the rules.