On Thu, Jun 19, 2014 at 11:01 AM, Amit Das <[email protected]> wrote:
> Hi All, > > Thanks for clarifying the Cinder behavior w.r.t a snapshot & its clones > which seems to be independent/decoupled. > The current volume & its snapshot based validations in Cinder holds true > for snapshot & its clones w.r.t my storage requirements. > > Our storage is built on top of ZFS filesystem. > Ahh.. yes, we've had similar discussions with Nexenta and other ZFS derivatives on this. The only thing I've thought of here is the use of some trickery in the form of "hidden/system" objects. It creates a bit of a quota nightmare and admin mess though. Maybe we can get all the ZFS folks (and I believe Ceph has some similar capabilities here) and come up with a solution that doesn't break the API behaviors. > The volume -> snapshot -> clone that I am referring to in turn points to a > ZFS dataset -> ZFS snapshot -> ZFS clone. > > The best part of ZFS based snapshots & clones are : > > - these are almost instantaneous ( i.e. copy-on-write based copies) > - these will not consume any additional (initially) > - a clone initially shares all its disk space with the original > snapshot, its used property is initially zero. > - As changes are made to the clone, it uses more space. > - The used property of the original snapshot does not consider the > disk space consumed by the clone. > > Further optimizations i.e. cool feature: > > - While creating VM clones, a hypervisor driver can delegate part of > its cloning process to storage driver & hence, the overall VM cloning will > be very very fast. > > > > > Regards, > Amit > *CloudByte Inc.* <http://www.cloudbyte.com/> > > > On Thu, Jun 19, 2014 at 9:16 PM, John Griffith < > [email protected]> wrote: > >> >> >> >> On Tue, Jun 17, 2014 at 10:50 PM, Amit Das <[email protected]> >> wrote: >> >>> Hi Stackers, >>> >>> I have been implementing a Cinder driver for our storage solution & >>> facing issues with below scenario. >>> >>> Scenario - When a user/admin tries to delete a snapshot that has >>> associated clone(s), an error message/log should be shown to the user >>> stating that '*There are clones associated to this snapshot. Hence, >>> snapshot cannot be deleted*'. >>> >> >> What's the use model of "clones associated with the snapshot"? What are >> these "clones" from a Cinder perspective. Easy answer is: don't create >> them, but I realize you probably have a cool feature or optimization that >> you're trying to leverage here. >> >>> >>> Implementation issues - If Cinder driver throws an Exception the >>> snapshot will have error_deleting status & will not be usable. If Cinder >>> driver logs the error silently then Openstack will probably mark the >>> snapshot as deleted. >>> >> >> So as others point out, from a Cinder perspective this is what I/we >> would expect. >> >> Scott made some really good points, but the point is we do not want to >> behave differently for every single driver. The agreed upon mission for >> Cinder is to actually provide a consistent API and set of behaviors to end >> users regardless of what backend device they're using (in other words that >> should remain pretty much invisible to the end-user). >> >> What do you use the Clones of the Snapshot for? Maybe we can come up >> with another approach that works and keeps consistency in the API. >> >> >> >>> What is the appropriate procedure that needs to be followed for above >>> usecase. >>> >>> Regards, >>> Amit >>> *CloudByte Inc.* <http://www.cloudbyte.com/> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
