Hi Paul

I posted a query to Ironic which is related to this discussion. My thinking was 
I want to ensure the case you note here (1) " a tenant can not read another 
tenants disk......" the next (2) was where in Ironic you provision a baremetal 
server that has an onboard dish as part of the blade provisioned to a given 
tenant-A. then when tenant-A finishes his baremetal blade lease and that blade 
comes back into the pool and tenant-B comes along, I was asking what open 
source tools guarantee data destruction so that no ghost images  or file 
retrieval is possible?

/Alan

-----Original Message-----
From: CARVER, PAUL [mailto:pc2...@att.com] 
Sent: January-15-14 6:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of 
cinder.

Chris Friesen [mailto:chris.frie...@windriver.com] wrote:

>I read a proposal about using thinly-provisioned logical volumes as a 
>way around the cost of wiping the disks, since they zero-fill on demand 
>rather than incur the cost at deletion time.

I think it make a difference where the requirement for deletion is coming from.

If it's just to make sure that a tenant can't read another tenant's disk then 
what you're talking about should work. It sounds similar (or perhaps identical 
to) how NetApp (and I assume others) work by tracking whether the current 
client has written to the volume and returning zeros rather than the actual 
contents of the disk sector on a read that precedes the first write to that 
sector.

However, in that case the previous client's bits are still on the disk. If they 
were unencrypted then they're still available if someone somehow got ahold of 
the physical disk out of the storage array.

That may not be acceptable depending on the tenant's security requirements.

Though one may reasonably ask why they were writing unencrypted bits to a disk 
that they didn't have physical control over.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to