Storage performance and I/O limits
Set volume I/O controls and interpret latency during replication and repair.
Volume I/O limits bound admitted traffic to a storage service. They do not reserve physical performance unless the selected storage class explicitly provides that reservation.
Set a volume limit
Open Volume → Performance and set read IOPS, write IOPS, read throughput, and write throughput independently. An unset value inherits the storage policy. A positive integer creates an explicit limit. Zero is rejected rather than interpreted as either unlimited service or a suspended volume.
Throughput limits use MiB per second in the console and bytes_per_second in
the API. IOPS counts requests after the storage path's documented request
accounting. Changing a throughput cap does not change the volume's logical size.
A policy can set a ceiling below a project's requested value. The effective configuration shows the inherited value and the limiting policy. Requests above that ceiling are rejected; Infra does not silently clamp them.
Observe queueing
Compare submitted I/O, completed I/O, queue depth, and latency. A volume at its configured limit can queue requests while devices have spare physical capacity. A volume below its limit can still experience latency from replication, device contention, or the guest filesystem.
Host disk metrics and guest application metrics have different observation points. Application latency includes filesystem, database, and network work that is not represented by a block-device service-time chart.
Replication and repair
Replicated writes depend on the policy's required locations. A slow required replica can affect completion latency even if the local device is idle. Repair traffic also consumes device and network capacity.
Set repair bandwidth through the pool's repair policy. Reducing it can protect foreground latency while extending the period of degraded redundancy. Raising it can shorten copying while increasing pressure on application I/O. Observe both foreground latency and repair backlog after a change.
Test a change
Run a representative workload on disposable test data. Record request sizes, read/write ratio, working set, cache state, and concurrency. A sequential read benchmark does not predict a synchronous database write workload.
Do not run destructive raw-device tests on an attached production volume. Create an isolated test volume under the same policy and verify that the test cannot address the original attachment.
Limits during migration and recovery
A cold copy or backup restore can be limited by source I/O, destination I/O, and the transfer path. Progress reflects the slowest active dependency. More API polling does not increase transfer throughput.
Use replica repair for degraded placement and Volume API for resource revisions. Review limits again after a storage-policy transition because inherited effective values can change.