...
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. For example, the 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 simply a constraint enables the Health Processor to take the appropriate action when needed to ensure disk-level and lifecycle data protection.
...
Guideline | Explanation | |||||
|---|---|---|---|---|---|---|
Make every lifepoint stand alone | Lifepoints do not build upon one another: they stand alone as a complete specification of the constraints that apply to the object in a given date range. Be sure to include Include the complete set of constraints for a given end date in the lifepoint header. Correct lifepoint
| |||||
Give time in GMT | For HTTP-date, adhere to the Full Date Section 3.3.1 of the HTTP/1.1 specification. This means the indicated time must be specified in Greenwich Mean Time (GMT). GMT is exactly equal to UTC (Coordinated Universal Time) when dealing with Swarm. | |||||
Do not use deletable= without reps= | The delete constraint does not store a value and cannot include end-date : Incorrect delete constraint
| |||||
Do not delete contexts by lifepoint | To protect content objects from being orphaned, Swarm does not allow lifepoint-triggered deletes of contexts (domains and bucket objects). See SCSP DELETE for guidance on deleting domains and buckets. | |||||
Do not replicate chunked uploads | Chunked uploads are erasure-coded automatically, so a request fails if it is chunked and the current lifepoint specifies replication. To convert a chunked upload, specify two lifepoints: have the first specify an EC encoding expiring in one day, and have the second specify the number of replicas going forward: Converting chunked to replication
| |||||
Do not expect Swarm to validate lifepoints | To maximize performance, Swarm does not validate lifepoints when they are added to the cluster. Swarm accepts an invalid lifepoint and later logs an error if the HP cannot parse the lifepoint. |
...
Constraint names and values are parsed by Swarm object classes called ConstraintSpecialists that maintain one or more related constraints. For example, the The reps constraint is parsed and maintained by the ReplicationConstraintSpecialist. In general, constraint names are case-sensitive, and constraint names not recognized by any of the ConstraintSpecialists are ignored. As a result, the set of allowable constraints is extensible, and new constraint types may be added to the system in future releases.
...