<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 15, 2015 at 11:38 AM, Eric Harney <span dir="ltr"><<a href="mailto:eharney@redhat.com" target="_blank">eharney@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09/15/2015 01:00 PM, Chris Friesen wrote:<br>
> I'm currently trying to work around an issue where activating LVM<br>
> snapshots created through cinder takes potentially a long time.<br>
> (Linearly related to the amount of data that differs between the<br>
> original volume and the snapshot.)  On one system I tested it took about<br>
> one minute per 25GB of data, so the worst-case boot delay can become<br>
> significant.<br></span></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​Sadly the addition of the whole activate/deactivate has been problematic ever since it was introduced.  I'd like to better understand why this is needed and why the long delay.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
> According to Zdenek Kabelac on the LVM mailing list, LVM snapshots were<br>
> not intended to be kept around indefinitely, they were supposed to be<br>
> used only until the backup was taken and then deleted.  He recommends<br></span></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​Correct, and FWIW this has also been the recommendation from Cinder's perspective for a long time as well.  Snapshots are NOT backups and shouldn't be treated as such.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> using thin provisioning for long-lived snapshots due to differences in<br>
> how the metadata is maintained.  (He also says he's heard reports of<br>
> volume activation taking half an hour, which is clearly crazy when<br>
> instances are waiting to access their volumes.)</span> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
> Given the above, is there any reason why we couldn't make thin<br>
> provisioning the default?<br></span></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​I tried, it was rejected.  I think it's crazy not to fix things up and do this at this point.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
<br>
<br>
</span>My intention is to move toward thin-provisioned LVM as the default -- it<br>
is definitely better suited to our use of LVM.  Previously this was less<br>
easy, since some older Ubuntu platforms didn't support it, but in<br>
Liberty we added the ability to specify lvm_type = "auto" [1] to use<br>
thin if it is supported on the platform.<br>
<br>
The other issue preventing using thin by default is that we default the<br>
max oversubscription ratio to 20.  IMO that isn't a safe thing to do for<br>
the reference implementation, since it means that people who deploy<br>
Cinder LVM on smaller storage configurations can easily fill up their<br>
volume group and have things grind to halt.  I think we want something<br>
closer to the semantics of thick LVM for the default case.<br>
<br>
We haven't thought through a reasonable migration strategy for how to<br>
handle that.  I'm not sure we can change the default oversubscription<br>
ratio without breaking deployments using other drivers.  (Maybe I'm<br>
wrong about this?)<br>
<br>
If we sort out that issue, I don't see any reason we can't switch over<br>
in Mitaka.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/104653/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/104653/</a><br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>