Open Stack

> > 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.