Ceph » mgr

More details about this clone functionality can be found here:

https://kubernetes.io/docs/concepts/storage/volume-pvc-datasource/

Let me give some more context here:

There are mainly 2 operations to create a new PVC ( empty volume creation is omitted here to avoid confusion).

1) From the snapshot 2) From an existing PVC

In the first case the `dataSource` field in the PVC will be referring to "Snapshot" and in the second case the data source will be referring to an `existing PVC`. The latter is "referred" as CLONE in kube. `A Clone is defined as a duplicate of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The only difference is that upon provisioning, rather than creating a “new” empty Volume, the back end device creates an exact duplicate of the specified Volume.`.

Regarding consistency: There wont be any inflight I/Os on the source PVC, so we are good to take a path of source copy directly to new volume

The data source can be defined in the second case like this:

```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: clone-of-pvc-1
namespace: myns
spec:
accessModes:
- ReadWriteOnce
storageClassName: cloning
resources:
requests:
storage: 5Gi
dataSource:
kind: PersistentVolumeClaim
name: pvc-1
```

Regarding consistency: There wont be any inflight I/Os on the source PVC, so we are good to take a path of source copy directly to new volume

Thanks for this clarification.

Humble,

As discussed in [1], it's decided that subvolume clone from another subvolume would not be implemented.
It doesn't makes sense to implement when subvolume creation from snapshot already exists.

Please close this tracker if there are no futher queries

[1] https://docs.google.com/document/d/1YddyUyGkTudPGA3hT3YjeMlvdlP-kqFl0_xwnVHe-88/edit

Thanks,
Kotresh HR