Lifepoint Conversions

The Health Processor maintenance mechanism converts objects as necessary between:

• Standard replication and erasure coding

• Erasure coding and standard replication

The Health Processor replicates the logical object back into the cluster with the new replication scheme when you configure your cluster settings for this type of conversion. The object is visible with some header changes, and the new object version supersedes the older version after the conversion. The source cluster is re-replicated to the target cluster as a new version of the object if the conversion is performed in a source cluster.

Content protection can change due to a set of explicitly specified lifepoint policies over time. An explicit lifepoint specification that includes a reps= value-either as a whole number or a colon-separated k:p EC encoding—takes precedence over any default cluster setting. This explicit conversion responds to explicit lifepoint specifications. Explicit conversions include replication to erasure coding, erasure coding to replication, and erasure coding to another erasure-encoding scheme.

Explicit conversions occur on the next Health Processor cycle following the lifepoint change.

Encoding Conversions

In addition to lifepoint conversions, the Health Processor performs encoding conversions when:

• The cluster includes a policy.ecEncoding value, which sets the number of data and parity segments to be used when erasure coding objects (for example. 5:2).

• The object is greater than the policy.ecMinStreamSize value, which indicates the minimum size (in bytes) for an object to be automatically erasure-coded.

If the object is replicated wholly, policy.ecEncoding is specified, and the object size is greater than the policy.ecMinStreamSize value, the object is converted to erasure coding. This implicit conversion occurs because of your cluster settings. Implicit conversions are used to convert legacy data-perhaps without lifepoints-to the default cluster encoding scheme, enabling legacy data to take advantage of the new capability. An object remains replicated at scsp.defreps replicas if the object is replicated and policy.ecEncoding is not configured or the object size is less than the policy.ecMinStreamSize value.

The Health Processor converts these objects at a slower rate than the next Health Processor cycle to balance its processing cycles between object conversions and other system requirements. The ec.conversionPercentage setting governs the conversion rate. The ec.conversionPercentage setting defaults to zero, which implies no implicit conversion. Until the object is converted, it is replicated with scsp.defreps reps.

Using Cache Coherency Headers After Erasure Coding

When the Health Processor converts objects from standard replication to erasure coding, it replaces the Etag and the Castor-System-Version header. When the if-match and if-none-match cache coherency headers compare the request header content against the Castor-System-Created header on the object (which does not change during the conversion), the headers believe the object has changed, even though the content data is actually the same. The cache coherency headers do not always operate as expected.

To achieve consistent results,

• Use if-modified-since and if-unmodified-since headers after erasure-coding conversion or during remote replication where either the original or destination object is erasure-coded.

• Do not use only the Etag header after an erasure-coding conversion because the header may inadvertently change during an object conversion.