<div dir="ltr">I would say that wipe-on-delete is not necessary in most deployments.<div><br></div><div>Most storage backends exhibit the following behavior:</div><div>1. Delete volume A that has data on physical sectors 1-10</div><div>2. Create new volume B</div><div>3. Read from volume B before writing, which happens to map to physical sector 5 - backend should return zeroes here, and not data from volume A</div><div><br></div><div>In case the backend doesn't provide this rather standard behavior, data must be wiped immediately.  Otherwise, the only risk is physical security, and if that's not adequate, customers shouldn't be storing all their data there regardless.  You could also run a periodic job to wipe deleted volumes to reduce the window of vulnerability, without making delete_volume take a ridiculously long time.</div><div><br></div><div>Encryption is a good option as well, and of course it protects the data before deletion as well (as long as your keys are protected...)</div><div><br></div><div>Bottom line - I too think the default in devstack should be to disable this option, and think we should consider making the default False in Cinder itself.  This isn't the first time someone has asked why volume deletion takes 20 minutes...</div><div><br></div><div>As for queuing backup operations and managing bandwidth for various operations, ideally this would be done with a holistic view, so that for example Cinder operations won't interfere with Nova, or different Nova operations won't interfere with each other, but that is probably far down the road.</div><div><br></div><div>Thanks,</div><div>Avishay</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 21, 2014 at 9:16 AM, Chris Friesen <span dir="ltr"><<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/19/2014 09:33 AM, Avishay Traeger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Preston,<br>
Replies to some of your cinder-related questions:<br>
1. Creating a snapshot isn't usually an I/O intensive operation.  Are<br>
you seeing I/O spike or CPU?  If you're seeing CPU load, I've seen the<br>
CPU usage of cinder-api spike sometimes - not sure why.<br>
2. The 'dd' processes that you see are Cinder wiping the volumes during<br>
deletion.  You can either disable this in cinder.conf, or you can use a<br>
relatively new option to manage the bandwidth used for this.<br>
<br>
IMHO, deployments should be optimized to not do very long/intensive<br>
management operations - for example, use backends with efficient<br>
snapshots, use CoW operations wherever possible rather than copying full<br>
volumes/images, disabling wipe on delete, etc.<br>
</blockquote>
<br></span>
In a public-cloud environment I don't think it's reasonable to disable wipe-on-delete.<br>
<br>
Arguably it would be better to use encryption instead of wipe-on-delete.  When done with the backing store, just throw away the key and it'll be secure enough for most purposes.<span class="HOEnZb"><font color="#888888"><br>
<br>
Chris</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>