> > I'm currently trying to work around an issue where activating LVM > > snapshots created through cinder takes potentially a long time. [[ thick LVM snapshot performance problem ]] > > Given the above, is there any reason why we couldn't make thin > > provisioning the default? > > My intention is to move toward thin-provisioned LVM as the default -- it > is definitely better suited to our use of LVM. ... > 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. The DRBDmanage backend has to deal with the same problem.
We decided to provide 3 different storage strategies: * Use Thick LVs - with the known performance implications when using snapshots. * Use one Thin Pool for the volumes - this uses the available space "optimally", but gives the oversubscription problem mentioned above. * Use multiple Thin Pools, one for each volume. This provides efficient snapshots *and* space reservation for each volume. The last strategy is no panacea, though - something needs to check the free space in the pool, because the snapshots can still fill it up... Without impacting the other volumes, though. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
