<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>
<div>Yes, Solum is interested in this too. Ideally we would like a way to specify the volume clear upon each volume creation, not in a configuration file. We would likely implement that as an attribute on the environment and assembly resources, which group
 various cloud resources similar to a stack in Heat. When we generate Heat templates, it would be nice to set meta data on the Heat stack that could indicate the default clear mode for any volume created within that stack.</div>
<div><br>
</div>
<div><br>
</div>
<div style="font-size:75%">--</div>
<div style="font-size:75%">Adrian</div>
<br>
<br>
-------- Original message --------<br>
From: "Fox, Kevin M" <br>
Date:01/15/2014 5:10 PM (GMT-08:00) <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>
<div>
<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 id="divRpF112714" style="direction:ltr"><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>
</div>
</body>
</html>