On 10/23/2014 04:24 PM, Preston L. Bannister wrote:
On Thu, Oct 23, 2014 at 3:04 PM, John Griffith <john.griffi...@gmail.com <mailto:john.griffi...@gmail.com>> wrote:The debate about whether to wipe LV's pretty much massively depends on the intelligence of the underlying store. If the lower level storage never returns accidental information ... explicit zeroes are not needed. On Thu, Oct 23, 2014 at 3:44 PM, Preston L. Bannister <pres...@bannister.us <mailto:pres...@bannister.us>> wrote: Yes, that is pretty much the key. Does LVM let you read physical blocks that have never been written? Or zero out virgin segments on read? If not, then "dd" of zeroes is a way of doing the right thing (if *very* expensive). Yeah... so that's the crux of the issue on LVM (Thick). It's quite possible for a new LV to be allocated from the VG and a block from a previous LV can be allocated. So in essence if somebody were to sit there in a cloud env and just create volumes and read the blocks over and over and over they could gather some previous or other tenants data (or pieces of it at any rate). It's def the "right" thing to do if you're in an env where you need some level of security between tenants. There are other ways to solve it of course but this is what we've got. Has anyone raised this issue with the LVM folk? Returning zeros on unwritten blocks would require a bit of extra bookkeeping, but a lot more efficient overall.
For Cinder volumes, I think that if you have new enough versions of everything you can specify "lvm_type = thin" and it will use thin provisioning. Among other things this should improve snapshot performance and also avoid the need to explicitly wipe on delete (since the next user of the storage will be provided zeros for a read of any page it hasn't written).
As far as I know this is not supported for ephemeral storage. Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
