2 ms·

Maybe for unattached instance storage this is possible (thought not a good business decision as others have noted). But you are forgetting how Amazon sees those

Maybe for unattached instance storage this is possible (thought not a good business decision as others have noted). But you are forgetting how Amazon sees those attached instance disks: As raw block devices from the hypervisor. They see a computer with an attached disk of, say, 1 TB. They don't see the filesystem at all. They don't know if a sequence of zeros is unused space, or are literally zeros in data. There is no way that Amazon can use slack space because they don't know what is slack space. This incomplete view of how disks (both instance and EBS) are used is also evident by what metrics CloudFront can track: CPU usage. Raw I/O stats for disk and network. To get richer metrics, you have to install scripts/agents running inside your EC2 instance which than beacon the info to CloudFront via the API. In short, Amazon's current setup means they cannot use the slack space inside of attached block devices, even if they wanted to.

justinsb 12y ago
The way thin provisioning normally works (e.g. on ZFS or LVM) is that only non-zero blocks are stored; an unstored block is read as zero; a block written as zeroes could be "unstored". It doesn't matter whether a block of zeroes is stored or not: it still reads as zero. So a cloud provider only needs to store non-zero blocks, and thus doesn't need to provision the full capacity to back a volume. As to whether EC2 does this I don't know - based on your observations they may not. I think it's an interesting way to build a storage product like Glacier, even if Amazon may have chosen to do something different.