On 06/04/2011 02:36, James Hawtin wrote:
On 06/04/2011 00:43, Stuart D. Gathman wrote:
In fact, since you still have to zero an LV before removing, you
might as well
zero an LV when you allocate. Same overhead. Then you don't need to
mess
with any of these schemes to deal with snapshots. Did we already cover
that obvious solution? We did discuss a utility to optimize zeroing an
already mostly zero LV.
I think you mean and lv of a virtual machine rather than snap shot,
not sure how you could zero the cow. Stuart does have a good point
here, there is another source of leak outside of snapshots (and
probably worse), if you delete an lv the create a new one over the
same PEs the data from then old lv will be there, save a few k that is
zeroed at the front (to help with fs/label creation). This is worse as
it is in order data that the cow from a snap is not. Geting a while fs
back is very possible.
Currently, as part of our procedure, we zero LVs once a customer has
left our service. The reason why we don't zero on allocation is that
customer usually expect quick setup times (under 10 minutes) and zeroing
gigabytes worth of space can take too long. Getting new zeroed LVs ready
before sign ups also isn't an option but for other reasons.
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
