Size of RepliStor Data folder!

Kamal

The problem is that your data is not being forwarded to your target system faster than it is changing on your source system. There can be various reasons for this but one common reason is that so many OC$ files build up during a period of instability that the system is unable to catch up.

My suggestion here would be to stop mirroring and forwarding from the Replistor console, delete data directory contents, either from the GUI or manually deleting the OC$, run an incremental sync and re-enable mirroring and forwarding.

If you still see issues then you may need to go back to your design to see if the amount of changes expected/observed on the source system can be handled by the connection to the target system.

Thanks dhamson for your valuable suggestions.

I would like to say that I can do what you have suggested but we might have a small problem. What really is happening is as follows:

1) The images come in through ApplicationXtender (AX) and are kept in E:\AXDATA
2) E:\AXDATA is managed by DiskXtender (DX) and are instructed to move to Centera and purged once they are moved.
3) Before purging, however, the data is replicated to the remote site using RepliStor.
4) On the remote site, remote DX will also move and purge to another remote Centera.

Now here, can we delete the data directory and run an incremental sync? Will RepliStor replicate the data which has been moved and purged to Centera? This is because we have setup RepliStor to note replicate the purged files (the stubs of DX) using the Processes option in RepliStor.

Hope I have made it clear to understand. Please do ask me if you don't understand anything.

Again, thanks a lot for your valuable suggestions.

Regards,
Kamal

I think I'll have to read that over a few more times to try to figure out what is going on! Let's just concentrate on the Replistor side of things first... Here is a quick explanation of how Replistor works (copied from an earlier post I made):

Replistor captures changes made to your file system and writes these file system changes both on the original and the target disk. In order to maintain integrity it has to apply these changes in the same order.

In normal operation Replistor will use a reserved part of memory called the kernel cache to capture these changes prior to them being forwarded to the target system. If however changes take place faster than the data can be forwarded (in this instance the target system is not accepting any data) then Replistor places this data in temporary OC$. Once it can forward the data it then reads the data from the OC$ on disk and continues to read OC$ files until they are all gone (in order to ensure data is being updated in order) at which time it will then resume using the kernel cache again. If you do get into a situation where you have a lot of these files build up all your changes rather than just pass through memory are being both written to local disk, then read, which is not the most efficient use of your processor.

The OC$ files are copies of the data you are replicating that have not been forwarded to the target system. If we delete these files then Replistor will sync the data in its current state - so if files have been moved/deleted this data will not be replicated... So the answer here is that we will lose some data if it has been moved to the Centera. However, my concern is also that Replistor may not recover, particularly if you are not seeing a gradual reduction of OC$ files.

There is no straightfoward answer to resolving this... I would suggest you stop moving data to the Centera box first of all so that we minimize issues with data that does not get replicated - if we cannot bring Replistor back into a stable state then we will need to do something drastic to bring it back into sync (clear down data directory and resync). Also look at possible reasons why this problem occured - were there connection issues between source and target, or was there a large amount of data suddenly requiring replication? Verify that this issue has now passed to give the system a chance to catch up, at least to the point where data has not been moved to the Centera box, from which you can then follow the procedure I suggested initially.

If I remember correctly, once you start the incremental sync, Replistor will pull the original files off the Centera and send them to the remote system. Check the DiskXtender release notes, the behavior is described in there.

Hi Tomislav,

Thanks for your response. Yes, RepliStor will pull the original files off Centera and replicate it over however, I have disabled that option in RepliStor. It does not replicate any files that have been purged. This can be done in the Processes Tab in the Options Dialog box in RepliStor (ignoring operations by processes).

For DiskXtender 2000¿ ¿ DiskXtender 2000 may migrate a file from
the source disk to an offline media. The operations used to
perform this migration should not be replicated, since it may
result in a truncation of that file¿s data on the target.

Regards,
Kamal

No, what you did is configured Replistor to ignore all actions on the files performed by the DiskXtender process, but not *vice versa*. If you start incremental sync Replistor will access each file causing it to be fetched from the offline media.
Not that I am not talking about mirroring after the specification is in sync, but the incremental sync.
To summarize, if you decide to clear up the kernel cache, you will have to resynchronize your specifications, and that means that all migrated files will be fetched from the offline medai during the sync, so keep that in mind.