You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Starting from Longhorn 1.3, when "type: snap" is configured in volume snapshot class, CSI snapshot requests (creation of VolumeSnapshot resource) results in a point in time Longhorn snapshot.
However, if a PVC is created with CSI snapshot as data source, a new Longhorn volume is created and data is copied to it from the snapshot. Because of the copy, PVC is not ready immediately and when it becomes ready depends on the amount of data being copied. More over, the new PVC will by default have same number of replicas as the source volume but this can be fixed by using a different storage class that sets number of replicas to 1. While the data copy is fine in many cases, there is one particular use case where it is problematic.
Backup applications (such as CloudCasa and Velero) typically create a PVC snapshot and then backup its content. To read data from snapshot, they create a temporary PVC from the snapshot and read from it. Once backup is done, the temporary PVC is deleted. In this particular case, it is inefficient to have data copy take place when PVC is created from snapshot. Ideally, new volume should be created from snapshot with no data copy as some storage systems do. If the new volume allows writes, modified blocks should be saved separately while reads for other blocks can be fulfilled from the snapshot.
I don't know Longhorn internals enough to tell whether this feature is feasible but I am opening this request after discussions with @PhanLe1010 in vmware-tanzu/velero#6179 (comment).
innobead, R-Studio, PhanLe1010, lucatr, MoZadro and 2 more