hesela.devToken bucket
A token bucket meters work using credits that refill at a configured rate up to a finite capacity.
Model: credits accumulate at rate R up to capacity B, and each admitted operation consumes its charge. A strict ideal bucket admits at most B + R*t charge units over an interval of t seconds. The unit may be bytes or operations; the initial balance and any additional peak limit matter. [1]
Storage scope: librbd QoS in Ceph Reef uses token buckets for IOPS and byte-rate limits. Limits apply to one image within one process; separate processes accessing the same image have independent limits. A configured ceiling is not a cluster-wide reservation. [2]
Whole-request boundary: in the strict model, an indivisible request costing more than B credits can never conform, because waiting refills only up to B. Loose meters that borrow credits require different reasoning. This is a model distinction, not a claim about Ceph's admission implementation. [1]
Relations
Limitations
- The admission envelope alone does not bound outstanding concurrency or completion latency. [1]
Citations
- RFC 3290, Appendix A: rate and burst models, metering and shaping
- Ceph Reef: RBD QoS settings and per-image, per-process scope
Further reading
Sources & caveats
- RFC 3290 is an informational networking model; the charge-unit envelope is applied here as ideal accounting, not a storage benchmark.
- Ceph behavior is scoped to the Reef documentation; no device performance or current deployment measurement is claimed.