rbd bench

Why this matters in production

rbd bench is built in and needs no extra packages, which makes it the fastest way to get a number. Knowing where it stops being sufficient prevents over-relying on it.

Running it

rbd create --size 100G rbd-vms/bench

rbd bench --io-type write --io-size 4K --io-threads 16 \
          --io-total 10G --io-pattern rand rbd-vms/bench

rbd bench --io-type read --io-size 4M --io-threads 16 \
          --io-total 20G --io-pattern seq rbd-vms/bench

# a mixed workload
rbd bench --io-type rw --rw-mix-read 70 --io-size 4K \
          --io-threads 32 --io-total 20G --io-pattern rand rbd-vms/bench

The output

elapsed: 42  ops: 2621440  ops/sec: 62415.24  bytes/sec: 255.68 MiB/s

Three numbers: elapsed time, total operations, and the rates. That is the whole output, and its brevity is both the tool’s convenience and its limitation.

Limitations relative to fio

The absence of percentiles is the significant one: an average operations-per-second figure says nothing about the tail, and the tail is what users experience.

Choosing between them

# cleanup
rbd rm rbd-vms/bench

Quiz

Production discipline

Use rbd bench for a quick capability check and fio whenever the result will inform a decision — the missing latency percentiles are exactly what distinguishes configurations users notice. Prefer time-based runs with a ramp period so results across runs are directly comparable.

Cross-course references

• Kubernetes: quick smoke tests and decision-grade benchmarks need different tools
• Linux: dd is convenient and hdparm is quick; neither replaces fio for a decision