---
id: "en/deployment-object-storage"
title: "Object storage and erasure coding"
language: "en"
description: "MinIO object storage, erasure coding, space utilization, hardware preparation and expansion instructions."
canonical_url: "https://www.babel.cc/public/babelwiki/en/deployment-object-storage.html"
markdown_url: "https://www.babel.cc/public/babelwiki/ai/en/deployment-object-storage.md"
alternates: {"en": "https://www.babel.cc/public/babelwiki/ai/en/deployment-object-storage.md", "zh": "https://www.babel.cc/public/babelwiki/ai/zh/deployment-object-storage.md"}
reading_note: "文档记录不等于当前部署能力；以实际版本、授权模块与配置为准。保留原文的可选、限制及待确认说明，勿补猜接口。 / Documentation is not a guarantee for every deployment. Preserve optional-module requirements, limitations and unresolved API contracts."
---

# 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](https://min.io/docs/minio/linux/operations/concepts/erasure-coding.html) and validate the actual delivery configuration.

![Distributed erasure coding](https://www.babel.cc/public/babelwiki/assets/images/object-storage-erasure-distributed.png)
*Protection applies within each object's erasure set, not by adding parity across the entire system.*

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](https://www.babel.cc/public/babelwiki/en/deployment-requirements.html) and [high availability](https://www.babel.cc/public/babelwiki/en/deployment-high-availability.html).