Erasure Code Settings
This page covers settings that configure the Erasure Code parity to use for objects written to the MinIO cluster. This impacts how MinIO uses the space on the drive(s) and how MinIO can recover objects stored on lost drives or similar issues.
You can establish or modify settings by defining:
- an environment variable on the host system prior to starting or restarting the MinIO Server. Refer to your operating system’s documentation for how to define an environment variable.
- a configuration setting using
mc admin config set.
If you define both an environment variable and the similar configuration setting, MinIO uses the environment variable value.
Some settings have only an environment variable or a configuration setting, but not both.
Important
Each configuration setting controls fundamental MinIO behavior and functionality. MinIO strongly recommends testing configuration changes in a lower environment, such as DEV or QA, before applying to production.
Standard Storage Class
Note
MinIO Storage Classes are distinct from AWS Storage Classes.
AWS Storage Classes refer to the specific storage tier on which to store a given object, such as hot or glacier storage. MinIO Storage Classes affect the erasure code parity setting used and relate to Availability and Resiliency of objects.
For tiering from one type of storage to another, such as for cost management purposes, see Object Transition (“Tiering”).
The parity level for the deployment. MinIO shards objects written with the default STANDARD storage class using this parity value.
MinIO references the x-amz-storage-class header in request metadata for determining which storage class to assign an object. The specific syntax or method for setting headers depends on your preferred method for interfacing with the MinIO server.
Specify the value using EC:M notation, where M refers to the number of parity blocks to create for the object.
The following table lists the default values based on the erasure set size of the initial server pool in the deployment:
| Erasure Set Size | Default Parity (EC:M) |
|---|---|
| 1 | EC:0 |
| 2-3 | EC:1 |
| 4-5 | EC:2 |
| 6 - 7 | EC:3 |
| 8 - 16 | EC:4 |
The 2–3 row describes the same default parity, not the same write availability. With EC:1, a two-drive set has a read quorum of 1 and a write quorum of 2, while a three-drive set has both quorums equal to 2. Losing one drive therefore prevents writes to the two-drive set. A single-drive EC:0 deployment has no erasure-code redundancy. See Erasure Coding.
The minimum supported value is 0, which indicates no erasure coding protections. These deployments rely entirely on the storage controller or resource for availability / resiliency.
The maximum value depends on the erasure set size N of the initial server pool in the deployment, with an upper bound of floor(N/2). For example, a deployment with erasure set stripe size of 16 has a maximum standard parity of 8.
You can change this value after startup to any value between 0 and the upper bound for the erasure set size. MinIO only applies the changed parity to newly written objects. Existing objects retain the parity value in place at the time of their creation.
Reduced Redundancy Storage Class
Note
MinIO Storage Classes are distinct from AWS Storage Classes.
AWS Storage Classes refer to the specific storage tier on which to store a given object, such as hot or glacier storage. MinIO Storage Classes affect the erasure code parity setting used and relate to Availability and Resiliency of objects.
For tiering from one type of storage to another, such as for cost management purposes, see Object Transition (“Tiering”).
The parity level for objects written with the REDUCED storage class.
MinIO references the x-amz-storage-class header in request metadata for determining which storage class to assign an object. The specific syntax or method for setting headers depends on your preferred method for interfacing with the MinIO server.
Specify the value using EC:M notation, where M refers to the number of parity blocks to create for the object.
When this value and MINIO_STORAGE_CLASS_STANDARD are both nonzero, this value must be less than or equal to STANDARD parity. Equal parity is allowed.
You cannot set this value for deployments with an erasure set size less than 2. Defaults to EC:1 for deployments with erasure set size greater than 1. Defaults to EC:0 for deployments of erasure set size of 1.
Parity Retention Optimization
The default availability setting allows SILO to increase parity for new objects when drives in the destination erasure set are offline, up to floor(N/2) parity shards for a set of N drives. The write must still satisfy the quorum for its resulting shard layout. This can improve redundancy for new objects, but does not guarantee unchanged availability. In particular, it cannot keep a two-drive EC:1 set writable after one drive becomes unavailable.
Specify capacity to this setting to direct MinIO to not create any additional parity for the object. This prioritizes the overall capacity of the cluster at the cost of potentially reduced object availability in the event more drives in that erasure set fail.
Comment
Adds a comment to the storage class settings.