<div dir="ltr">Avishay,<div><br></div><div>Thanks for the tip on [cinder.conf] volume_clear. The corresponding option in devstack is <span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">CINDER_SECURE_DELETE=False. </span></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Also I *may* have been bitten by the related bug:</span></div><div><font color="#000000" face="arial, sans-serif"><a href="https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1023755">https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1023755</a></font><br></div><div><font color="#000000" face="arial, sans-serif"><br></font></div><div><font color="#000000" face="arial, sans-serif">(All I know at this point is the devstack VM became unresponsive - have not yet identified the cause. But the symptoms fit.)</font></div><div><font color="#000000" face="arial, sans-serif"><br></font></div><div><font color="#000000" face="arial, sans-serif">Not sure if there are spikes on Cinder snapshot creation. Perhaps not. (Too many different failures and oddities. Have not sorted all, yet.)</font></div><div><font color="#000000" face="arial, sans-serif"><br></font></div><div><font color="#000000" face="arial, sans-serif">I am of the opinion </font><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">CINDER_SECURE_DELETE=False should be a default for devstack. Especially as it invokes bug-like behavior.</span></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Also, unbounded concurrent "dd" operations is not a good idea. (Which is generally what you meant, I believe.)</span></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Onwards....</span></div><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font color="#000000" face="arial, sans-serif"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 19, 2014 at 8:33 AM, Avishay Traeger <span dir="ltr"><<a href="mailto:avishay@stratoscale.com" target="_blank">avishay@stratoscale.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Preston,<div>Replies to some of your cinder-related questions:</div><div>1. Creating a snapshot isn't usually an I/O intensive operation.  Are you seeing I/O spike or CPU?  If you're seeing CPU load, I've seen the CPU usage of cinder-api spike sometimes - not sure why.</div><div>2. The 'dd' processes that you see are Cinder wiping the volumes during deletion.  You can either disable this in cinder.conf, or you can use a relatively new option to manage the bandwidth used for this.</div><div><br></div><div>IMHO, deployments should be optimized to not do very long/intensive management operations - for example, use backends with efficient snapshots, use CoW operations wherever possible rather than copying full volumes/images, disabling wipe on delete, etc.</div><div><br></div><div>Thanks,</div><div>Avishay</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Oct 19, 2014 at 1:41 PM, Preston L. Bannister <span dir="ltr"><<a href="mailto:preston@bannister.us" target="_blank">preston@bannister.us</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">OK, I am fairly new here (to OpenStack). Maybe I am missing something. Or not.<div><br></div><div>Have a DevStack, running in a VM (VirtualBox), backed by a single flash drive (on my current generation MacBook). Could be I have something off in my setup.</div><div><br></div><div>Testing nova backup - first the existing implementation, then my (much changed) replacement.</div><div><br></div><div>Simple scripts for testing. Create images. Create instances (five). Run backup on all instances.</div><div><br></div><div>Currently found in:</div><div><a href="https://github.com/dreadedhill-work/stack-backup/tree/master/backup-scripts" target="_blank">https://github.com/dreadedhill-work/stack-backup/tree/master/backup-scripts</a><br></div><div><br></div><div>First time I started backups of all (five) instances, load on the Devstack VM went insane, and all but one backup failed. Seems that all of the backups were performed immediately (or attempted), without any sort of queuing or load management. Huh. Well, maybe just the backup implementation is naive...</div><div><br></div><div>I will write on this at greater length, but backup should interfere as little as possible with foreground processing. Overloading a host is entirely unacceptable.</div><div><br></div><div>Replaced the backup implementation so it does proper queuing (among other things). Iterating forward - implementing and testing. </div><div><br></div><div>Fired off snapshots on five Cinder volumes (attached to five instances). Again the load shot very high. Huh. Well, in a full-scale OpenStack setup, maybe storage can handle that much I/O more gracefully ... or not. Again, should taking snapshots interfere with foreground activity? I would say, most often not. Queuing and serializing snapshots would strictly limit the interference with foreground. Also, very high end storage can perform snapshots *very* quickly, so serialized snapshots will not be slow. My take is that the default behavior should be to queue and serialize all heavy I/O operations, with non-default allowances for limited concurrency.</div><div><br></div><div>Cleaned up (which required reboot/unstack/stack and more). Tried again.<br><br>Ran two test backups (which in the current iteration create Cinder volume snapshots). Asked Cinder to delete the snapshots. Again, very high load factors, and in "top" I can see two long-running "dd" processes. (Given I have a single disk, more than one "dd" is not good.)</div><div><br></div><div>Running too many heavyweight operations against storage can lead to thrashing. Queuing can strictly limit that load, and insure better and reliable performance. I am not seeing evidence of this thought in my OpenStack testing. <br><br>So far it looks like there is no thought to managing the impact of disk intensive management operations. Am I missing something?<br><br><br></div><div><br></div><div><br></div></div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>