<br><br><div class="gmail_quote">On Thu, Nov 8, 2012 at 2:02 AM, Avishay Traeger <span dir="ltr"><<a href="mailto:AVISHAY@il.ibm.com" target="_blank">AVISHAY@il.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi all,<br>
I had a few questions about snapshot support in Cinder:<br>
1) a. Why is a snapshot a fundamentally different entity than a volume?<br>
   b. Is it because some back-ends don't support the same set of operations<br>
on snapshots?<br>
   c. Is this what the snapshot-to-volume operation was meant to achieve?<br>
   d. If a back-end supports nested snapshots, each snapshot will need to<br>
be converted to volume before a nested snapshot can be taken?<br>
   e. And in this case, will the back-end driver simply do nothing for the<br>
snapshot-to-volume operation?<br>
2) Why can't you take snapshots of attached volumes?  I think most/all<br>
back-ends will be fine with it (of course they will be crash-consistent if<br>
the OS/application doesn't sync to disk).<br>
3) Most back-ends support various types of snapshots - e.g., read-only,<br>
read-write, full copy, etc.  How can we better support this notion?<br>
<br>
Thanks,<br>
Avishay<br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote></div><br><div>Hi Avishay,</div><div><br></div><div>So we have plans to improve some of this in the Grizzly release, here's a few thoughts:</div><div>>> a. Why is a snapshot a fundamentally different entity than a volume?</div>
<div>I've asked this question a number of times myself :)  There are a number of different ideas/definitions of what a snapshot is, versus a clone, versus a backup, etc etc</div><div><br></div><div>I've proposed that we leave snapshots as they are today and introduce a clone option to just directly get a new volume to work with and move on, as well as the ability to restore a volume to a specific snapshot (the originating volume, not a new one).  I don't know how popular this idea is though, there were a number of folks at the Summit that seemed to think that was crazy talk.</div>
<div><br></div><div>>> c. Is this what the snapshot-to-volume operation was meant to achieve?</div><div>Yep<br><br></div><div>>> d. If a back-end supports nested snapshots, each snapshot will need to<br>>> be converted to volume before a nested snapshot can be taken?</div>
<div>>> e. And in this case, will the back-end driver simply do nothing for the<br>>> snapshot-to-volume operation?</div><div><div>Not sure I follow here...</div><div><br></div>>>2) Why can't you take snapshots of attached volumes?  I think most/all<br>
>>back-ends will be fine with it (of course they will be crash-consistent if<br>>>the OS/application doesn't sync to disk).</div><div>Worth investigating for those back-ends that support it</div><div><br>>>3) Most back-ends support various types of snapshots - e.g., read-only,<br>
>>read-write, full copy, etc.  How can we better support this notion?</div><div>Not sure how I feel about trying to match up to every option every vendor might have.  The reality also is that there are differences in definitions from vendor A to vendor B on these sorts of things.</div>
<div><br></div><div>The direction I was going with snapshots, clones would *kinda* give at least part of what you're talking about here.</div><div><br></div><div>I started a blueprint for this sort of thing here: <a href="https://blueprints.launchpad.net/cinder/+spec/add-cloning-support-to-cinder">https://blueprints.launchpad.net/cinder/+spec/add-cloning-support-to-cinder</a>, feel free to add suggestions or give me feed-back if you like.  It's by no means complete, but I should be working on it week after next.</div>
<div><br></div><div>Thanks,</div><div>John</div>