[openstack-dev] [cinder] Dependencies of snapshots on volumes
Arkady_Kanevsky at DELL.com
Arkady_Kanevsky at DELL.com
Wed Dec 9 17:32:06 UTC 2015
You can do lazy copy that happens only when volume or snapshot is deleted.
You will need to have refcount on metadata.
-----Original Message-----
From: Li, Xiaoyan [mailto:xiaoyan.li at intel.com]
Sent: Tuesday, December 08, 2015 10:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [cinder] Dependencies of snapshots on volumes
Hi all,
Currently when deleting a volume, it checks whether there are snapshots created from it. If yes deletion is prohibited. But it allows to extend the volume, no check whether there are snapshots from it.
The two behaviors in Cinder are not consistent from my viewpoint.
In backend storage, their behaviors are same.
For full snapshot, if still in copying progress, both extend and deletion are not allowed. If snapshot copying finishes, both extend and deletion are allowed.
For incremental snapshot, both extend and deletion are not allowed.
As a result, this raises two concerns here:
1. Let such operations behavior same in Cinder.
2. I prefer to let storage driver decide the dependencies, not in the general core codes.
Meanwhile, if we let driver to decide the dependencies, the following changes need to do in Cinder:
1. When creating a snapshot from volume, it needs copy all metadata of volume to snapshot. Currently it doesn't.
Any other potential issues please let me know.
Any input will be appreciated.
Best wishes
Lisa
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151209/5d68ef64/attachment-0001.html>
More information about the OpenStack-dev
mailing list