Storing encrypted first does affect performance but it is generally much less and more predictable (doing a big secure delete on a drive inflicts an immediate and unexpected hit on that part of a storage array).
We think encryption is also just a lot more robust. If you don't lay down the data in the first place in readable form on the physical drives, its eliminates a lot of data leakage possibilities.
Best wishes,
Patrick
Have you ever looked at a freshly mounted EBS volume on EC2? It shows all zero's for me. And I'm almost sure that was not just a coincidence for the volumes I looked at.
Moreover there are more efficient ways than encryption or "full sweep overwrite" to address this at the storage-level.
"there are more efficient ways than encryption or "full sweep overwrite" to address this at the storage-level."
Your suggestion would be?
Kind regards,
Patrick
See my reply above about using a loopback-file.
It's a one-liner:
dd if=/dev/zero of=/vols/customer123/vol234 seek=$SIZE bs=1 count=1
There's surely quite a few other ways to skin this cat (eventually arriving at the multi-tenancy features in proprietary SAN appliances), but this seems the most obvious one.The issue there is more about tracking. You'd have to track every single block and return zero for any that hadn't been used/altered since drive creation. I'm guessing it would prove pretty costly in terms of latency for drive access after initial drive creation but its a good idea potentially. I'll pass it onto our technical guys as well to ask about its feasibility.
Best wishes,
Patrick