Using Lifepoint Metadata Headers; About Storage Policies; A Simple Lifecycle Example - Dell DX6000 Application Manual

Chapter 16. Using Lifepoint Metadata Headers
This chapter discusses the optional lifepoint header, which defines a DX Storage storage policy for
the associated object.
For a list of all metadata headers supported by DX Storage, see

16.1. About Storage Policies

Each node in a DX Storage cluster has a component called the Health Processor that continuously
cycles through the list of content objects it stores on disk. The Health Processor first determines
what is considered "healthy" for this object at this particular point in its lifecycle.
For example, an object might need to have at least three replicas of itself stored within DX Storage.
A condition such as "this object must have at least three replicas," is referred to as a content
constraint, or simply a constraint.
A constraint can be specified only when the object is first stored, and cannot be changed.
Constraints can be grouped together and given an expiration date. Such a dated constraint group is
called a content lifepoint, or lifepoint, because it represents a point at which the health requirements
of an object change.
A sequence of lifepoints is referred to a storage policy, or a content lifecycle.

16.2. A Simple Lifecycle Example

The simple syntax used by clients to specify a complete lifecycle for an object it wishes to store
is discussed in more detail in
demonstrates the concepts using a simple example.
The example shows the following:
• Assume the object was written to DX Storage on June 12, 2007.
• In the first six months of its life, an object must have at least three replicas and is not deletable by
any user.
• In the second six months of its life, the object can have as few as one replica and client
applications can delete the object.
• After a year, the object is automatically deleted.
Note
If there is one replica of an object in a cluster, then there is one instance of that object.
Replica, instance and object are all synonymous in this usage. It would also be correct to
say that there is one instance of the object in the cluster.
Lifepoint: [Fri,12 Dec 2007 15:59:02 GMT] reps=3, deletable=no
Lifepoint: [Wed, 08 Jun 2008 15:59:02 GMT] reps=1, deletable=yes
Lifepoint: [] delete
Each time the Health Processor performs a check-up on this object, it checks the current date to
see which of these three possible lifepoints apply. If it's not December 12, 2007 yet, the Health
Processor attempts to make sure there are at least three replicas of the object stored in the cluster.
Copyright © 2010 Caringo, Inc.
All rights reserved
Section 16.3, "Lifepoint/Lifecycle
60
the Content Metadata
Specification". This section
appendix.
Version 5.0
December 2010