On Fri, Nov 1, 2013 at 8:33 PM, David Hill <david.h...@ubisoft.com> wrote: > Hello John, > > Well, if it has an impact on the other volumes that are still being > used by > some other VMs, this is worse in my opinion as it will degrade the service > level > of the other VMs that need to get some work done. If that space is not > immediately > needed we can take our time to delete it or at least delay the deletion. Or > perhaps > the scheduler should try to delete the volumes when there's less activity on > the storage > device (SAN, disks, etc) and even throttle the rate at which the bites are > overwritten > by zeros. The fact is that our internal cloud users can delete multiple > volumes at > the same time and thus, have an impact on other users VMs that may or may not > be doing critical operations and sometimes, Windows may even blue screen > because > of the disk latency and this is very bad. > > Here are the answer to the alternatives: > 1) I don't think we do need secure delete but I'm not the one who will make > this call but > If I could, I would turn it off right away as it would remove some stress > over the storage > Systems. For some folks, this can be a compliance problem. If an organization is using a cloud provider, then it could be a governance issue too. See, for example, NIST Special Publication 800-63-1 and the discussions surrounding zeroization.
Jeff _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
