EC2 (local) instance storage

Posted Dec 10, 2012 2:55 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: EC2 (local) instance storage by dlang
Parent article: Optimizing stable pages

They are using #3. The raw device reads on initialized areas return zeroes.

EC2 (local) instance storage

Posted Dec 10, 2012 3:27 UTC (Mon) by dlang (guest, #313) [Link] (3 responses)

that eliminates #2, but it could be #1 or #3

It seems like trying to keep a map of if this block has been written to would be rather expensive to do at the hypervisor level, particularly if you are talking about large drives.

Good to know that you should get zeros for uninitialized sectors.

EC2 (local) instance storage

Posted Dec 10, 2012 3:30 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

#1 is unlikely because local storage is quite large (4Tb on some nodes). It's not hard to keep track of dirtied blocks, they need it to support snapshots on EBS volumes anyway.

EC2 (local) instance storage

Posted Dec 10, 2012 6:18 UTC (Mon) by bjencks (subscriber, #80303) [Link] (1 responses)

Just to be clear, there are two different ways of initializing storage: root filesystems are created from a full disk image that specifies every block, so there are no uninitialized blocks to worry about, while non-root instance storage and fresh EBS volumes are created in a blank state, returning zeros for every block.

It's well documented that fresh EBS volumes keep track of touched blocks; to get full performance on random writes you need to touch every block first. That implies to me that they don't even allocate the block on the back end until it's written to.

Not sure how instance storage initialization works, though.

EC2 (local) instance storage

Posted Dec 10, 2012 6:34 UTC (Mon) by dlang (guest, #313) [Link]

EBS storage is not simple disks, the size flexibility and performance you can get cannot be supported by providing raw access to drives or drive arrays.

As you say, instance local storage is different.