About volume_child_dependency() and volume_child_dependency_rm()

[Gris Ge]

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?

Thank you in advance.
Best regards.

[1] Fix required: some volume might have snapshot based clone where
split is required:
https://library.netapp.com/ecmdocs/ECMP1368845/html/GUID-CC1CE192-6C31-49C7-B703-116CA1D6C86F.html

[2] For special clone like NetApp FlexClone, if not split is required,
False would be OK.

[Tony Asleson]

Post by Gris Ge
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().
* 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.
* 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.
* 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
Waiting ongoing copy tile finish.
Convert all target volume to normal volume.
Convert this volume to normal volume.
Convert all target/DR volume to normal 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