Don't Panic — Storage Fundamentals

A storage service is what turns retained data into something an application can ask for again. The disk is only one member of the cast. There is also an interface, a namespace, a request path, media, caches, controllers, and a recovery plan. Calling all of that the disk is how an innocent-looking diagram becomes a small work of fiction.

The first fork in the road is the access model. Block storage gives a host numbered blocks, which leaves that host to create partitions and file systems. File storage gives clients named files and directories through a shared service. Object storage gives an application objects, identifiers, metadata, and an API. These are not three spellings for capacity. They decide who owns the namespace and which applications can use it without pretending to be something else.

Capacity also has a habit of putting on a false moustache. Raw capacity is installed media. Usable capacity has already paid for mirrors, parity, formatting, metadata, reserved space, and headroom. Performance is similarly uncooperative: IOPS, throughput, and latency only mean something beside request size, read and write mix, randomness, concurrency, queue depth, cache state, and working-set size. Averages can remain perfectly calm while tail latency is having a difficult afternoon.

The serious distinction is between availability, durability, and recovery. A service answering requests now is not the same promise as acknowledged data surviving a failure, and neither proves that lost or corrupted data can be restored. A failure domain is the set of components that fail together; copies inside one controller, power, network, site, software, or credential boundary are not independent for that failure. The Cheatsheet keeps the definitions close. The Slides show the choices as a system. Field Notes concentrates on the assumptions that fail in practice. The Reference tab is where exact product and protocol behavior stops being politely general.