Object Storage and Erasure Coding
BabelBird can use a MinIO-based object-storage solution for file content. Validate capacity, failure domains and operations against the delivered version. Third-party laboratory throughput is not a BabelBird performance commitment.
How It Works
An object is divided into data and parity shards within an erasure set: N = K + M. Recovery requires enough healthy shards in that object's set; continued writes also require write quorum. See the MinIO erasure-coding documentation and validate the actual delivery configuration.
Losing half the drives does not universally preserve service. Coding parameters, failure distribution, quorum and metadata affect availability. Erasure coding is redundancy, not encryption; storage access still requires access control, encryption and key management.
Capacity Examples
Ignoring formatting, metadata, versions and operating headroom:
Theoretical usable capacity = raw capacity × K / (K + M)
| Mathematical example | Capacity | Failure boundary |
|---|---|---|
| Eight 10TB drives in two independent 3+1 sets | 80TB × 3/4 = 60TB | One missing shard per set; two failed drives in the same set can prevent recovery |
| Eight 10TB drives in one 7+1 set | 80TB × 7/8 = 70TB | One missing shard in that set; actual read/write quorum still applies |
These examples explain arithmetic, not supported configurations for every delivery. Allow for growth, versions, recycle-bin retention, maintenance, independent backups and TB/TiB differences.
Deployment and Expansion
Single-server multi-drive storage can tolerate some disk failures but not loss of the whole server. Distributed designs must account for node, rack, power and network failures. A data/parity ratio alone does not specify a server count.
Confirm drive layout, set size, expansion batches and online expansion conditions with the implementation team. Do not edit backend storage directories directly. Monitor repair completion and retain independent backups.
See server requirements and high availability.