There are numerous books describing this in much greater detail, but here is a short description and my opinion:

BCV is a defined attribute/relationship which keeps track of changes between cycles of establish/split. This is the way EMC has done local disk based replication for quite some time. The downside is that you have to copy between a standard and a BCV and there are limitations on what type of protection you can have on a BCV. Newer microcode levels have introduced things like Raid protection for BCV devices, but you are still required to define a device as a BCV device to perform BCV operations.

Timefinder clone is relatively newer (within the last 3-4 years) software which allows you to perform local disk-to-disk based replication between pretty much any type of device within a frame. An example being that you could copy between a mirrored set of standards and a Raid protected set of standards. The big disadvantage is that the map which keeps track of changes between operations is not persistent like it is for BCV devices. However, in newer microcode releases (72 and above I believe) they have made this a feature to keep clone maps between uses making them functionally a lot more like BCV relationships. I also believe (could be wrong) that a clone does not consume a mirror position in the same way that a BCV device does. There are also a few more options such as copy-on-demand (where tracks are copied as they are accessed) which can reduce I/O which are not currently available with BCV devices.

My opinion - TimeFinder clone is most likely going to replace/supersede BCV relationships in some future release of EMC microcode. I take this as an attempt to break some of the legacy structure EMC has within their products. BCVs will be around for quite some time given how ingrained they are within EMC and other vendor products, but I do expect that clone will become the local replication product in the not too distant future.

Yes - this is based on dated information - I was testing out SYMCLONE on a box running microcode 69. Looks like in 5671 and above is when SDDF comes into play for tracking changes - in early versions a terminate was the only way to make the target device accessible:

"You can use the symclone split command to split a clone device pair that is in the
Restored state. This command requires Enginuity Version 5671 or later.
This feature uses SDDF to keep track of the changed data, allowing for subsequent
incremental operations, such as a recreate, incremental establish, or another restore command."

Sorry for some dated information, but if you are trying to run SYMCLONE on an older box with older code then my point still stands. I should have checked the level this behavior changed befor posting my original reply.

what do you mean by that ?..clone session utilizes SDDF to keep track of changed blocks, so if the clone session is created using -diff flag ..you are getting your incremental bcv sync functionality. The only issue i have seen so far is if you perform symclone restore, you can not turn around and re-create that clone session with incremental sync ..you will have to terminate your clone session and create/activate new session which results in full sync.

hi all,
just to keep it simple :
BCV copy (timefinder mirror) is a full copy of a standard hyper on a BCV volume which can be refreshed in a differential way when needed.
Clone copy (timefinder clone) is a much more "flexible" way to make a copy of a symmetrix volume (yes, you can have your clones behave as bcv copies ) . I don't list here all the features you have when using clones (there are tons of literature), but the main I suppose is that you can copy using nearly any hyper as source and any hyper as target within your symmetrix box.
bye

Absolutly right ... TF/Mirror will use a mirror position (except if you use SYMCLI_CLONE_EMULATION or if you use RAID5-BCVs) while TF/Clone won't use a mirror position.

The main difference between TF/Clone and TF/Mirror is the point in time when the actual copy of data on the "other" device really ends.

With TF/Mirror (when you use BCVs and the symmir command) when you do issue the "symmir split" command you have a full copy of your data on the BCV devices.
With TF/Clone when you issue the "symclone activate" (that's quite similar to the split command) you DO have an usable copy BUT the tracks are still copying from the source to the target.

For a lot of applications choosing clones vs BCVs is quite the same ..

But think about using Clones or BCVs for a big DWH.
With BCVs when you do split and startup the DB you are using a fully-independent copy of your production data. You can run heavy-duty queries and issue full-table scans whithout hitting the production devices.
With Clones when you'll run heavy queries that will issue an heavy I/O workload on the devices, you can hurt the production system (since the workload on the clones will force the DMX to copy the tracks still to be copied from the source to the target).

Will Clones superceed BCVs ?? No .. They address different needs .. they will live together and you (our beloved customer) will be able to choose what you want

Yep .. the difference is that with symmir you have the full copy as soon as you issue the "split" command while with clones you need to wait after the "activate" command and you can't know how long you need to wait before having a full copy on the clones.

Dear Stefano,
If we talk about "In which moment I get a full copy of my standard?" then
I agree with you that after firing a "symmir split" you have your copy but,
first you have to wait for your BCV to have their status as "Synchronized".
To keep it brief :
BCV ----> establish....wait....split (you have your copy).....finish
CLONE -----> create (-copy if you want a full copy)....activate (you have your snapshot)....wait....finish (you have your final copy)

is the difference in when you wait?

best regards
Gianluca

You can achieve the same thing with the -precopy option on a symclone. i.e. copy your data before you activate, then you would have a full, separate copy at the time of activation.

IClones can do every thing BCVs can, and more.

The -precopy option will force the copy process to begin when you create a session but will not guarrantee that when you activate the session all the data will be already on the Target volume.

After creating the session with -precopy you must wait a "full precopy cycle" (and take great care of that if you use SRDF/A and want to clone R2 devices). If the production host DO change a track on the SRC volume after the precopy job copied the track on the TGT, you still have a track that needs to be copied AFTER the activation.

If you don't wait a "full precopy cycle" and do activate the clones, you still have tracks on the SRC that needs to be copied on the TGT.

As you can see "-precopy" does not give a full copy on the TGT when you activate the session

I agree, there are small differences in how things get done, but my point was that it is possible to have your data fully copied (or darn close) when you activate if you use precopy far enough in advance.

Sometimes small problems (for you) may be big problems for someone else

"Darn close" is quite different from "fully copied" .. If you loose the superblock of a filesystem, you loose only a block .. but the truth is that you may have lost the whole filesystem

And also "far enough" isn't something you can measure in hours or minutes .. With -precopy the right answer is "A precopy cycle" but you can't know how long will it take 'till you do create the session and start waiting with symclone -cycled -precopy verify

Is symclone DIFFERENT then symmir ?? YES.. Is symclone BETTER then symmir ?? Don't know .. It depends

here is an exerpt from TimeFinder doc ...

You can use the -precopy option with the create argument to start copying tracks in
the background, before activating the copy session. This allows the early movement
of data before the point-in-time clone copy is established.
Pre-copying can occur in the Created or Recreated state. While in this state, the
pre-copy process keeps checking for new writes to be pre-copied to the target device
until the copy session is activated. ***Once activated, the normal background copy
mechanism starts and the pre-copy operation ends.***

corrected me if i am wrong ..as far as TGT device concerned ..it's a consistent copy after activation ..even though a track did not get copied when it was still doing -precopy ..but as soon as you activate it ..it will copy those missed tracks to the TGT anyway. But to me from host perspective the TGT device is a full right after activation ..if there is a request for a block that has not been copied yet ..it will go and get it from the SRC.

So i think it all depends from what perspective you look at it. If i am a host ..i am ready to read/write as soon as it's active ..even though it's still doing background sync, so i am not sure why you would say that somebody would miss a portion of their file system if -precopy did not finish and session got activated?

yeah ..i agree with you on the difference between TF mirror and TF Clone and what happens in the background. You assumption is that something happens with the SRC while background sync is progress and i mean physical failure ..but if that block has been captured by PIT ...it can be erased, overwritten whatever ..it's copy on write/copy on access ..it will be copied to the TGT before anything is done to it.