<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">That option is too corse. For some vm's, for testing for example, I really dont need it clearing the data, and for some of my tests, I was creating 6 vm's with 4, 40 gig volumes
each all on one test machine and it was taking several minutes to whipe each stack create/delete cycle I was doing while debugging the heat templates. At the same time, There are other volumes that I really do want cleared, just not the test ones. I'm guessing
its something the Solum project might run into too. You may not need to wipe a test deployment, but really want to wipe a production deployment, for example, both of which may be in the same tenant?<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF112714"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Jay S Bryant [jsbryant@us.ibm.com]<br>
<b>Sent:</b> Wednesday, January 15, 2014 4:30 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.<br>
</font><br>
</div>
<div></div>
<div><font face="sans-serif" size="2">There is already an option that can be set in cinder.conf using 'volume_clear=none'</font>
<br>
<br>
<font face="sans-serif" size="2">Is there a reason that that option is not sufficient?<br>
</font><br>
<font size="3"><b><i><br>
Jay S. Bryant</i></b><br>
<i>IBM Cinder Subject Matter Expert & Cinder Core Member</i></font> <br>
<font size="3"><br>
Department 7YLA, Building 015-2, Office E125, Rochester, MN<br>
Telephone: (507) 253-4270, FAX (507) 253-6410<br>
TIE Line: 553-4270<br>
E-Mail: jsbryant@us.ibm.com<br>
--------------------------------------------------------------------<br>
All the world's a stage and most of us are desperately unrehearsed.<br>
-- Sean O'Casey<br>
--------------------------------------------------------------------</font> <br>
<br>
<br>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">From: </font><font face="sans-serif" size="1">"Fox, Kevin M" <Kevin.Fox@pnnl.gov></font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">To: </font><font face="sans-serif" size="1">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>,
</font><br>
<font color="#5f5f5f" face="sans-serif" size="1">Date: </font><font face="sans-serif" size="1">01/15/2014 06:06 PM</font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">Subject: </font><font face="sans-serif" size="1">Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.</font>
<br>
<hr noshade="">
<br>
<br>
<br>
<tt><font size="2">What about a configuration option on the volume for delete type? I can see some possible options:<br>
<br>
* None - Don't clear on delete. Its junk data for testing and I don't want to wait.<br>
* Zero - Return zero's from subsequent reads either by zeroing on delete, or by faking zero reads initially.<br>
* Random - Write random to disk.<br>
* Multipass - Clear out the space in the most secure mode configured. Multiple passes and such.<br>
<br>
Kevin<br>
________________________________________<br>
From: CARVER, PAUL [pc2929@att.com]<br>
Sent: Wednesday, January 15, 2014 2:59 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.<br>
<br>
Chris Friesen [</font></tt><a href="mailto:chris.friesen@windriver.com" target="_blank"><tt><font size="2">mailto:chris.friesen@windriver.com</font></tt></a><tt><font size="2">] wrote:<br>
<br>
>I read a proposal about using thinly-provisioned logical volumes as a<br>
>way around the cost of wiping the disks, since they zero-fill on demand<br>
>rather than incur the cost at deletion time.<br>
<br>
I think it make a difference where the requirement for deletion is coming from.<br>
<br>
If it's just to make sure that a tenant can't read another tenant's disk then what<br>
you're talking about should work. It sounds similar (or perhaps identical to) how<br>
NetApp (and I assume others) work by tracking whether the current client has<br>
written to the volume and returning zeros rather than the actual contents of the<br>
disk sector on a read that precedes the first write to that sector.<br>
<br>
However, in that case the previous client's bits are still on the disk. If they were<br>
unencrypted then they're still available if someone somehow got ahold of the<br>
physical disk out of the storage array.<br>
<br>
That may not be acceptable depending on the tenant's security requirements.<br>
<br>
Though one may reasonably ask why they were writing unencrypted bits to<br>
a disk that they didn't have physical control over.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font size="2">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size="2"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font size="2">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size="2"><br>
<br>
</font></tt><br>
</div>
</div>
</div>
</body>
</html>