Updated Erasure Coding for warm storage (markdown)

Erasure-Coding-for-warm-storage.md

@@ -88,6 +88,14 @@ EC shard re-balancing happens in three steps:
 
 Destination volume/racks for EC shards are selected based on capacity, favoring those with less preexisting shards in order to ensure an uniform distribution. Additionally, EC shards selection obey default [replica placement settings](Replication#the-meaning-of-replication-type) for the master server.
 
+#### Rack-total cap
+
+In addition to the per-type caps, both new encodes (`Place`) and rebalancing (`ec.balance -apply`, worker `ec_balance` task via `Plan`) cap the *total* shards (data + parity) per rack. On a cluster with free space this is `ceil(shards/racks)` — e.g. 10+4 over 8 racks holds at most 2 shards per rack. The cap rises only when racks lack room, so encoding never fails for the cap alone (`PlaceDurabilityFirst` relaxes it last; `PlaceStrict` keeps it hard).
+
+This bounds correlated loss: losing `k` racks loses at most `k × cap` shards, and the volume survives while that is at most the parity count. With 8 racks (cap 2) a 10+4 volume survives losing any two racks; with 5 racks (cap 3) it does not.
+
+If the cap had to be raised for a volume, `ec.balance` prints it and the worker logs a warning — treat it as a capacity / spread signal, not a clean bill of health.
+
 ## How the read works?
 When all data shards are online, the read for one file key are assigned to one volume server (A) that has at least one data shard for the volume. Server A will read its copy of index file, and locate the volume server (B), and read from server B for the file key.