Chunkservers needed for an Erasure Coding scheme
The parts of a chunk stored in Erasure Coding are placed on separate Chunkservers. Parts that share a server are moved to separate servers as a repair. MooseFS decides the format from two counts of Chunkservers rather than one. Converting chunks from whole copies into parts needs the higher count. Keeping chunks that are already in parts needs the lower count. Both figures count servers, not disks, so a second disk on a server that is already counted changes neither figure.
Choosing between copies and Erasure Coding lists which schemes exist and what each scheme costs in space. The Community Edition accepts one parity part and rejects a Storage Class that requires more.
| Scheme | Chunkservers to convert to parts | Chunkservers to keep parts |
|---|---|---|
@4+1 | 6 | 5 |
@4+2 PRO (PRO Edition only) | 8 | 6 |
@4+3 PRO (PRO Edition only) | 10 | 7 |
@4+4 PRO (PRO Edition only) | 12 | 8 |
@4+5 PRO (PRO Edition only) | 14 | 9 |
@4+6 PRO (PRO Edition only) | 16 | 10 |
@4+7 PRO (PRO Edition only) | 18 | 11 |
@4+8 PRO (PRO Edition only) | 20 | 12 |
@4+9 PRO (PRO Edition only) | 22 | 13 |
@8+1 | 10 | 9 |
@8+2 PRO (PRO Edition only) | 12 | 10 |
@8+3 PRO (PRO Edition only) | 14 | 11 |
@8+4 PRO (PRO Edition only) | 16 | 12 |
@8+5 PRO (PRO Edition only) | 18 | 13 |
@8+6 PRO (PRO Edition only) | 20 | 14 |
@8+7 PRO (PRO Edition only) | 22 | 15 |
@8+8 PRO (PRO Edition only) | 24 | 16 |
@8+9 PRO (PRO Edition only) | 26 | 17 |
Plan one Chunkserver above the conversion count
Both figures are thresholds. A threshold is a minimum to stay above, not a target to build to. A location that has exactly the conversion count of Chunkservers is one machine away from the count at which conversions stop. The most frequent failure in a cluster is the loss of a single Chunkserver. That loss leaves the parts that the server already holds intact. The loss also blocks every new conversion until the server reconnects. A Chunkserver that keeps connecting and disconnecting crosses the threshold in both directions each time.
One server above the conversion count covers that case. Plan @8+2 for 13 Chunkservers rather than 12, and @8+1 for 11 rather than 10. The same rule applies to every scheme in the table: one more than the left-hand figure. That one server deliberately covers a single failure and no more. Two servers lost at once stop conversions again. A design that has to survive two servers lost at once requires a scheme with more parity parts, not more spare servers under this scheme.
Each location counts its own Chunkservers
Both counts are taken inside a location PRO (PRO Edition only), not across the cluster. A Storage Class that requires Erasure Coding in more than one location reaches the figure in each location separately. @8+2 in three locations therefore requires 12 Chunkservers in every location, not 12 across all three.
A label expression narrows the two counts separately
A label expression can put a count on the Chunkservers that the expression selects instead of on every Chunkserver in the location. The two counts are not always narrowed together. Under the STANDARD labels mode, a definition with one expression counts only the selected servers for converting to parts. For keeping parts, the same definition counts every Chunkserver in the location. When a count applies to the selected servers, the figure for that count is the number of servers that the expression has to select. Label expressions and matching describes which mode narrows which count. The same page also describes what a definition with separate expressions for data parts and parity parts counts.
Below a count, chunks convert rather than vanish
Both counts decide only the format that a chunk is stored in. A chunk below either count is converted. Such a chunk is never refused and never lost. Erasure Coding: part layout describes what each threshold triggers, in both directions.