Skip to content
Calcrivo

OpenStack Swift Storage Calculator

Size a Swift object ring: raw capacity for the replica count, drive count, object count and partitions per drive.

Inputs

TB
MiB
bits

2^power partitions; pick 100 partitions per drive at maximum planned scale.

TB
%
%

Raw Capacity Required

1 PiB

Drives Required

110drives

Objects Stored

119,209,290objects

Partitions in the Ring

65,536partitions

Partition Replicas per Drive

1,787.3per drive

Partition Power Verdict

Very high partition count per drive — replication and auditing overhead will be heavy

Step by step

  1. Values used

    Logical object data = 500 TB; Average object size = 4 MiB; Ring protection = 3 replicas (default); Partition power = 16 bits; Size of each drive = 18 TB; Filesystem and metadata overhead = 5 %; Maximum drive utilisation = 80 %

  2. OpenStack Swift Storage

    raw = logical data × replica factor × (1 + filesystem overhead); drives = raw ÷ (drive size × maximum utilisation); partition replicas per drive = 2^partition power × replicas ÷ drives.

  3. Raw Capacity Required

    = 1,575,000,000,000,000

  4. Drives Required

    = 110 drives

  5. Objects Stored

    = 119,209,290 objects

  6. Partitions in the Ring

    = 65,536 partitions

  7. Partition Replicas per Drive

    = 1,787.3 per drive

  8. Partition Power Verdict

    = Very high partition count per drive — replication and auditing overhead will be heavy

How it works

Swift stores each object once per replica across distinct failure domains, so raw capacity is logical data times the replica factor plus filesystem overhead. Partition power is the number that cannot be changed easily: the ring is fixed at 2^power partitions, and you pick it so that the largest cluster you ever plan to build still averages around 100 partition replicas per drive. Partition power is effectively a one-way decision — too low and data never balances across a grown cluster, too high and replicators and auditors spend all day walking directories — so it is worth calculating against your five-year drive count, not today's.

Formula

OpenStack Swift Storage

raw = logical data × replica factor × (1 + filesystem overhead); drives = raw ÷ (drive size × maximum utilisation); partition replicas per drive = 2^partition power × replicas ÷ drives.

replica factor
Raw bytes per logical byte — 3 for the default three-replica ring
partition power
Exponent fixing the ring at 2^power partitions, effectively permanent
partition replicas per drive
Placement granularity; roughly 100 is the target

Frequently Asked Questions

How is OpenStack Swift Storage calculated?

raw = logical data × replica factor × (1 + filesystem overhead); drives = raw ÷ (drive size × maximum utilisation); partition replicas per drive = 2^partition power × replicas ÷ drives. Swift stores each object once per replica across distinct failure domains, so raw capacity is logical data times the replica factor plus filesystem overhead. Partition power is the number that cannot be changed easily: the ring is fixed at 2^power partitions, and you pick it so that the largest cluster you ever plan to build still averages around 100 partition replicas per drive.

Why does OpenStack Swift Storage matter?

Partition power is effectively a one-way decision — too low and data never balances across a grown cluster, too high and replicators and auditors spend all day walking directories — so it is worth calculating against your five-year drive count, not today's.

What values do I need to enter?

This calculator takes 7 inputs: Logical object data, Average object size, Ring protection, Partition power, Size of each drive, Filesystem and metadata overhead, Maximum drive utilisation. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why does object count matter as well as capacity?

Swift keeps container database rows per object, so many small objects stress the container layer long before the drives fill. A ring holding a billion 4 KiB objects needs container sharding attention that a ring holding the same bytes as large objects does not.

You might also need