Reed-Solomon RS(5,2)
SkyeConnex’s baseline erasure coding, not a fixed rule. Each frame is split into 5 data shards and 2 parity shards; any 5 of the 7 reconstruct it, up to 2 can be lost or compromised without data loss, and no single shard reveals plaintext. The coding then adapts per upload — to the file’s size and to the provider pool your policy leaves — and only ever widens.
RS(5,2) is the baseline, not the rule. Two things move it, and both are decided once per upload, before anything is written:
The pool. When geo policy, sensitivity and routing leave a provider pool that could not survive losing a vendor at the baseline, the parity widens. The data-shard count never changes, and durability never decreases — adaptation only ever widens.
The file. Small files trade cheap bytes for survivability and large files trade a slice of durability for efficiency: RS(4,4) under 1 MB, RS(5,3) to 100 MB, RS(8,3) to 1 GB, RS(12,4) above it.
Both carry hard overhead ceilings. When no admissible coding survives the pool, the baseline stands and the upload falls back to a wider pool rather than quietly accepting weaker protection. See adaptive erasure coding.
Related
- SkyeConnex Architecture — the technical deep-dive that situates this term in the full platform.
- How SkyeConnex Works — the step-by-step pipeline.
- Cryptographic Posture — every primitive in active use with its NIST/FIPS reference.
- Whitepaper v1.2 — the consolidated reference document.
Posts that mention Reed-Solomon RS(5,2)
Reed-Solomon erasure coding for storage: a practical primer
Reed-Solomon codes are decades old. They're suddenly central to sovereign cloud architecture. Here's what they do, the math you need, and th…
Read → Architecture · 7 min readWhy multi-cloud RAID beats multi-cloud sync
Most multi-cloud storage products replicate your file inside each provider. SkyeConnex erasure-codes it across them. That distinction is the…
Read →