...
Each node in a storage cluster includes a Health Processor that continuously cycles through the list of content objects it stores on disk to determine what is considered "healthy" for each object at this particular point in the lifecycle. The Health Processor may determine an object needs to have at least three replicas of itself stored within Swarm. This requirement referred to as a content constraint or a constraint enables the Health Processor to take the appropriate action when needed to ensure verify disk-level and lifecycle data protection.
...
The ReplicationConstraintSpecialist maintains the desired level of redundancy of content objects and ensures verifies they are stored in the most efficient manner. It understands one constraint name: reps, which is set by protection type:
...
The ReplicationConstraintSpecialist does this by ensuring verifying the actual number of replicas or segments for an object is equal to reps at all times. A default value is supplied from the node or cluster configuration if a replication constraint is missing from the lifepoint. Cluster administrators have control over some aspects of replication behaviors through Swarm configuration parameters:
Replicas – Place limits on the number of replicas that can be specified by defining policy.replicas min and max.
EC – Specify the ec.minParity to ensure verify all objects have a minimum number of parity segments included for protection. Invalid or conflicting values of the reps constraint are ignored, defaults are used, and warnings are written to the log if found in a lifepoint. Lifepoints with erasure coding define what EC level to apply. For example: lifepoint = [] reps=5:2 expresses an erasure-coded level of 5 data segments and 2 parity segments.
...