Open Stack

On Fri, Nov 1, 2013 at 8:33 PM, David Hill <david.hill at 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