Open Stack

On Tue, Sep 15, 2015 at 11:38 AM, Eric Harney <eharney at redhat.com> wrote:

> On 09/15/2015 01:00 PM, Chris Friesen wrote:
> > I'm currently trying to work around an issue where activating LVM
> > snapshots created through cinder takes potentially a long time.
> > (Linearly related to the amount of data that differs between the
> > original volume and the snapshot.)  On one system I tested it took about
> > one minute per 25GB of data, so the worst-case boot delay can become
> > significant.
>
​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.
​


> >
> > According to Zdenek Kabelac on the LVM mailing list, LVM snapshots were
> > not intended to be kept around indefinitely, they were supposed to be
> > used only until the backup was taken and then deleted.  He recommends
>
​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.
​


> > using thin provisioning for long-lived snapshots due to differences in
> > how the metadata is maintained.  (He also says he's heard reports of
> > volume activation taking half an hour, which is clearly crazy when
> > instances are waiting to access their volumes.)

>
> > Given the above, is there any reason why we couldn't make thin
> > provisioning the default?
>
​I tried, it was rejected.  I think it's crazy not to fix things up and do
this at this point.
​


> >
>
>
> My intention is to move toward thin-provisioned LVM as the default -- it
> is definitely better suited to our use of LVM.  Previously this was less
> easy, since some older Ubuntu platforms didn't support it, but in
> Liberty we added the ability to specify lvm_type = "auto" [1] to use
> thin if it is supported on the platform.
>
> The other issue preventing using thin by default is that we default the
> max oversubscription ratio to 20.  IMO that isn't a safe thing to do for
> the reference implementation, since it means that people who deploy
> Cinder LVM on smaller storage configurations can easily fill up their
> volume group and have things grind to halt.  I think we want something
> closer to the semantics of thick LVM for the default case.
>
> We haven't thought through a reasonable migration strategy for how to
> handle that.  I'm not sure we can change the default oversubscription
> ratio without breaking deployments using other drivers.  (Maybe I'm
> wrong about this?)
>
> If we sort out that issue, I don't see any reason we can't switch over
> in Mitaka.
>
> [1] https://review.openstack.org/#/c/104653/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150915/648f3561/attachment.html>