Open Stack

HI Beyh,

According to the changes made in [1], volumes are not cleared when
"volume_clear=none"

[1]
https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20


On Fri, May 23, 2014 at 9:46 PM, Udara Liyanage <udaraliyanage at gmail.com>wrote:

> HI John,
>
> Thanks for the detailed answer.
> Just one more clarification. If "lvm_type=thin" will it clear only the
> blocks which data are written on?
>
>
> On Fri, May 23, 2014 at 8:51 PM, John Griffith <
> john.griffith at solidfire.com> wrote:
>
>>
>>
>>
>> On Thu, May 22, 2014 at 11:33 PM, Ruzicka, Marek <
>> marek.ruzicka at t-systems.sk> wrote:
>>
>>> Can’t help you here… I’m still running Grizzly, and volume resize came
>>> in IceHouse I believe.
>>>
>>>
>>>
>>> Marek
>>>
>>>
>>>
>>>
>>>
>>> *From:* Udara Liyanage [mailto:udaraliyanage at gmail.com]
>>> *Sent:* 23. mája 2014 07:28
>>> *To:* Ruzicka, Marek
>>> *Cc:* openstack at lists.openstack.org
>>> *Subject:* Re: [Openstack] Large volume creation takes long time
>>>
>>>
>>>
>>> HI marek,
>>>
>>> Thanks for the reply.
>>> By the way how to resize a volume to zero. I found "cinder extend"
>>> command where volumes can be extended. How to shrink the volume to zero?
>>>
>>>
>>>
>>> On Fri, May 23, 2014 at 10:52 AM, <marek.ruzicka at t-systems.sk> wrote:
>>>
>>> I’m not 100% sure, but I remember (depending on the driver you are
>>> using) it used to zero entire volume before deletion, which might or might
>>> not make sense for you.
>>>
>>> Sorry for not being able to provide any details, this is just something
>>> I remember from way back.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Marek
>>>
>>>
>>>
>>> *From:* Udara Liyanage [mailto:udaraliyanage at gmail.com]
>>> *Sent:* 23. mája 2014 07:00
>>> *To:* openstack at lists.openstack.org
>>> *Subject:* [Openstack] Large volume creation takes long time
>>>
>>>
>>>
>>> Hi,
>>>
>>> When it tries to delete a large sized volume, it takes a long time. Is
>>> there a another better way to do  this such as resizing a volume to zero.
>>>
>>>
>>> --
>>>
>>> Udara S.S Liyanage.
>>> Software Engineer at WSO2.
>>> Commiter and PPMC Member of Apache Stratos.
>>> Blog - http://udaraliyanage.wordpress.com
>>>
>>> phone: +94 71 443 6897
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Udara S.S Liyanage.
>>> Software Engineer at WSO2.
>>> Commiter and PPMC Member of Apache Stratos.
>>> Blog - http://udaraliyanage.wordpress.com
>>>
>>> phone: +94 71 443 6897
>>>
>>> _______________________________________________
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to     : openstack at lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>> ​The writing zeros to the volume on delete is indeed what you're seeing,
>> it's a "feature" that is there for security purposes, so for example a
>> public provider doesn't hand out a new volume to a tenant with the
>> possibility of allocating blocks with somebody elses data on them.
>>
>> You can switch to using "lvm_type=thin" in your cinder.conf file which
>> will basically handle this by returning zero for blocks that haven't been
>> written yet (so we don't do the secure delete).  Or as was suggested if you
>> don't need the secure delete option you can turn it off altogether by
>> setting "volume_clear=none" in your cinder.conf file.
>>
>> As far as adjusting the size to zero, we don't allow reducing the volume
>> size, only extending.  Reducing introduces quite a bit of risk and also it
>> doesn't address the problem that secure_delete is there for anyway.
>>
>> Thanks,
>> John​
>>
>>
>
>
> --
> Udara S.S Liyanage.
> Software Engineer at WSO2.
> Commiter and PPMC Member of Apache Stratos.
> Blog - http://udaraliyanage.wordpress.com
> phone: +94 71 443 6897
>



-- 
Udara S.S Liyanage.
Software Engineer at WSO2.
Commiter and PPMC Member of Apache Stratos.
Blog - http://udaraliyanage.wordpress.com
phone: +94 71 443 6897
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140523/948d83d0/attachment.html>