On 07/10/2015 12:26 AM, Gris Ge wrote:
Hi Guys,
To draft document about volume replication, I would like to start a
thread discussing design of volume_child_dependency() and
volume_child_dependency_rm().
Background about replication types:
* COPY
Full bitwise copy of the data (occupies full space).
* CLONE
Point in time read writeable space efficient copy of data.
* MIRROR_ASYNC
I/O will be blocked until I/O reached source storage systems.
The source storage system will use copy the changes data to
target system in a predefined interval. There will be a small
data differences between source and target.
* MIRROR_SYNC
I/O will be blocked until I/O reached both source and target
storage systems. There will be no data difference between
source and target storage systems.
Current implementation(not listed is considered as NO_SUPPORT):
* volume_replication()
* ONTAP: CLONE (NetApp FlexClone, no split required)
* Nstor: NO_SUPPORT
* SMIS: COPY and CLONE
* volume_child_dependency()
* ONTAP: Always return False.[1]
* Nstor: Depending on get_child_prop API. I am still seeking
the document. Anyone?
* SMI-S: Not implemented. The NO_SUPPORT error will be raised.
Generally, current implementation is almost NULL.
Definition maybe:
* The 'volume_child_dependency' means whether certain volume
could be deleted without impacting (data access, integrity,
redundancy) other volume.
COPY(ing) COPY(done) CLONE MIRROR
-------------------------------------------------------------
source volume True False True[2] True
target volume True False False True
* The 'volume_child_dependency_rm' means split the replicate
relationship:
* COPY:
Waiting ongoing copy tile finish.
* CLONE:
* Call against source volume:
Convert all target volume to normal volume.
* Call against target volume:
Convert this volume to normal volume.
* MIRROR_ASYNC / _SYNC:
* Call against source/productive volume:
Convert all target/DR volume to normal volume.
* Call against target/DR volume:
Convert this DR volume to normal volume.
Any suggestions?
Hi Gris,
I believe what you have outlined here is a good clarification of these
two methods with the different use cases. Originally when I placed them
in the library it was to address the need for implementations where
'cloned' volumes had a dependency with one another and instead of
providing an interface to express those dependencies to simply query and
remove them.
Regards,
Tony