[Openstack] Large volume creation takes long time
Beyh, Yehia
Yehia.Beyh at hp.com
Fri May 23 15:57:15 UTC 2014
I believe that the volume delete will clear the volume first (dd if=/dev/zero).
The volume resize option was implemented in Havana.
You can try to resize to 1G instead of 0.
I hope this helps.
-Yehia
From: John Griffith [mailto:john.griffith at solidfire.com]
Sent: Friday, May 23, 2014 11:21 AM
To: Ruzicka, Marek
Cc: Udara Liyanage; openstack at lists.openstack.org
Subject: Re: [Openstack] Large volume creation takes long time
On Thu, May 22, 2014 at 11:33 PM, Ruzicka, Marek <marek.ruzicka at t-systems.sk<mailto: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<mailto:udaraliyanage at gmail.com>]
Sent: 23. mája 2014 07:28
To: Ruzicka, Marek
Cc: openstack at lists.openstack.org<mailto: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<mailto: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<mailto:udaraliyanage at gmail.com>]
Sent: 23. mája 2014 07:00
To: openstack at lists.openstack.org<mailto: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<http://udaraliyanage.wordpress.com/>
phone: +94 71 443 6897<tel:%2B94%2071%20443%206897>
--
Udara S.S Liyanage.
Software Engineer at WSO2.
Commiter and PPMC Member of Apache Stratos.
Blog - http://udaraliyanage.wordpress.com<http://udaraliyanage.wordpress.com/>
phone: +94 71 443 6897<tel:%2B94%2071%20443%206897>
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack at lists.openstack.org<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140523/ecd9c143/attachment.html>
More information about the Openstack
mailing list