Open Stack

On Fri, May 23, 2014 at 10:16 AM, 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
>

​Hi Udara,

When you use LVM Thin it implicitly solves the problem that secure delete
was introduced for.  In other words, it won't give out previous written
blocks.  It keeps a table of the blocks that have been written since
allocation, if you try and read a block that isn't listed in the table as
written, it will automatically just return "zero".  Thus we don't need to
worry on the Cinder side about trying to zero out written blocks etc.

FWIW, we've looked at doing what you suggest on the thick/linear version
(track the written blocks and only zero those out) but personally I've just
kind of moved on to using Thin provisioning instead. There are a number of
other advantages associated with it as well which just made it a much
better fit for a lot of people.  It still doesn't support mirroring which
is too bad, but for the most part it's a better choice (IMHO).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140523/d9def369/attachment.html>