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
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
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.