Centera SDK: Setting retention - Clip data duplicated?

All of the API calls relating to metadata work on the local in memory version of the CDF. To persist any changes you have to write the clip - which gives a new MD5 and a new clip.

So - yes, that is not just the recommended way but the only way. Also note that the data is not duplicated, just the metadata of the CDF (as the tags in the new CDF point to the same blob object as the original).

Situation: A Tool developed for us for content deletion works in two separate steps (proccesses asynchron to each other) by doing:

a) TriggerEBREventWithPeriod

clipRef = FPClip_Open(poolRef, p_sCenteraClipID, FP_OPEN_ASTREE);

FPClip_TriggerEBREventWithPeriod (clipRef, nPeriod );

FPClipID outClipID;

FPClip_Write(clipRef,outClipID);

b) Delete

FPClip_Delete(poolRef,p_sCenteraClipID);

Question 1: Are there now both Clips (p_sCenteraClipID and outClipID) deleted?

Question 2: Must or should we do it like in the 3.2p5 sdk samples? This would lead to updating the database with the changed clipid?

     Update retention

     write clip

     delete original clip

     update db with newly created clipid

     delete newly created clip?

Question 3: Is it OK to use for b) the original clip ID for delete? Is the other ClipID also deleted than?

Background: Try to delete 11 million clips from about 80 million in two replicating clusters

Our EMC Centera Clusters (1+2 replicating) has HDD in storage nodes that are 100% capacity full (don't ask why, they are and we have to cope with it) and clips on those HDD can not be updated by TriggerEBREventWithPeriod because we get error -100156 (no space left) on write clip. But we know that we have 30% of all clips we WANT to delete on HDD that has capacity < 100%.

Problem: EMC support can not help to get a list of Clips that are on HDD < 100% Capacity. So we need to try to update retetion and see if it is going well. We learned that we have to set the retrycount = 0 to be able to process TriggerEBREventWithPeriod without timeouts.

Question 4: Can we explicetely request the write clip on the other Cluster in any way, avoiding the -100156 error?

Any more hints to do better than now?

Kind Regards

Frank Schulte

EBR and Litigation Hold are mutable metadata. When you trigger an EBR event (or change the Litigation Hold state) then the Clip Write does not result in a new Clip ID. So, in the example you gave, p_sCenteraClipID and outClipID are equal.

The only way of triggering the event on the eligible clips if to (somehow!) free up space on the cluster to allow for the creation of the new non-binding object associated with the clip.