Glossary
Block storage
Block storage presents storage capacity as a volume divided into fixed-size units called blocks, each identified by a number. The system using the volume decides what the blocks contain; the storage device stores and returns them without interpreting the data inside.
Block storage is the form in which drives themselves present capacity, and the form that operating systems, file systems and databases are built to consume. A block device offers three operations: read a range of blocks, write a range of blocks, and flush pending writes to stable media. It has no concept of a file, a name or a directory. Every layer above it supplies that structure.
Blocks, sectors and addressing
A block device exposes a linear array of fixed-size units. Each unit is identified by a logical block address, an integer counting from zero. A request names a starting address and a length: read eight blocks beginning at address 1,048,576.
Drives used 512-byte sectors for several decades. Drives manufactured since approximately 2010 use 4,096-byte physical sectors, a layout that reduces the per-sector overhead of error-correction data, and many of them present 512-byte logical blocks to the host for compatibility with older software. The two sizes coexist: a 4,096-byte physical sector underneath, a 512-byte logical block above it.
Capacity follows directly from block size. A 1 TB volume of 4,096-byte blocks contains 1012 divided by 4,096, or 244,140,625 addressable blocks. The address is the only identifier the device holds. It keeps no record of which file, table or virtual machine a block belongs to, and no record of whether a block is in use at all.
The layers above a block device
A raw volume is rarely consumed directly. Between the device and an application sit several layers, each translating a more descriptive request into block addresses.
A partition table divides a volume into ranges of blocks that can be treated independently. A volume manager can do the reverse, presenting several physical devices as one logical volume, or striping a logical volume across them.
A file system supplies names, directories and variable-length files. It maintains its own structures inside the volume: records describing each file, maps of which blocks are allocated, and usually a journal that records pending changes so an interrupted write can be resolved on restart. A request to read 200 bytes from the middle of a file becomes a lookup in those structures followed by a read of the blocks holding that region.
Some consumers skip the file system. Databases have historically used raw volumes so that their own page layout and write ordering are not mediated by a second set of allocation decisions. Virtualization adds a layer in the other direction: a virtual machine's disk is usually a file on a file system, which itself sits on a block volume, so a guest write passes through two block layers and two allocation maps.
Block protocols and transports
A command set defines the operations; a transport carries them. The two vary independently.
| Command set | Transport | Typical use |
|---|---|---|
| ATA | SATA | Directly attached consumer and nearline drives |
| SCSI | SAS | Directly attached enterprise drives and disk shelves |
| SCSI | Fibre Channel | Storage area networks |
| SCSI | TCP/IP, as iSCSI | Block volumes carried over an ordinary Ethernet network |
| NVMe | PCI Express | Flash devices attached to the host bus |
| NVMe | TCP, RDMA or Fibre Channel, as NVMe over Fabrics | Flash reached across a network with NVMe semantics |
The queue model differs sharply between the older and newer command sets. SCSI and ATA were designed around a single command queue, which suited a mechanical drive serving one request at a time. NVMe allows up to 65,535 input/output queues with up to 65,536 commands each, because a flash device serves many requests concurrently and the host has many cores able to submit them. The command set, rather than the medium alone, therefore sets a ceiling on how much concurrency a device can be given.
Block, file and object storage compared
The three models differ in what a request names and in what the storage system knows about the data.
| Block | File | Object | |
|---|---|---|---|
| Unit of access | A fixed-size block | A byte range within a named file | A whole object identified by a key |
| Addressing | Numeric block address | Path through a directory tree | Key within a bucket |
| Metadata held by the storage system | None beyond the address | Name, size, timestamps, permissions | Size, timestamps, content type, application-supplied fields |
| Partial update | Any block may be rewritten | Any byte range may be rewritten | Conventionally the whole object is replaced |
| Concurrent access by many hosts | Requires a coordinating layer above | Managed by the file system protocol | Native to the API |
| Typical consumers | Databases, virtual machine disks, boot devices | Shared directories, application data, home directories | Backups, media, datasets, archives |
A block device's lack of metadata is the reason it is fast and the reason it is limited. Nothing has to be looked up before a read, and nothing above the block layer can be reconstructed from the device alone. A volume whose file system structures are damaged still contains every block, with no way to determine which blocks formed which file. Further detail on the file and object models is covered in object storage and object storage vs. NAS.
Provisioning, snapshots and sharing
A volume is created at a declared size. Under thick provisioning the full capacity is reserved when the volume is created. Under thin provisioning capacity is drawn from a shared pool as blocks are first written, so the sum of declared volume sizes can exceed the physical capacity behind them.
Snapshots record a volume's state at an instant. The common implementation is copy-on-write: the snapshot initially references the live blocks, and a block is copied aside at the moment it is first overwritten after the snapshot was taken. Space consumed therefore grows with the rate of change rather than with the size of the volume, and a snapshot of a large but static volume costs very little.
A block volume is normally attached to one host. Two hosts writing to the same volume through independent file systems will corrupt it, because each maintains its own allocation map and neither is aware of the other's writes. Shared access requires either a cluster file system that coordinates allocation across hosts, or a protocol layer that serves files rather than blocks.
Performance characteristics
Block workloads are dominated by small operations. A database page is commonly 8 or 16 KB, a file system block 4 KB, and both generate many independent requests rather than long sequential transfers. The relevant measurements are therefore operations per second and per-operation latency more often than aggregate bandwidth. Storage latency and sequential vs. random I/O cover those measurements in detail.
Alignment is specific to the block model. When a 4,096-byte logical write begins at an offset that is not a multiple of the 4,096-byte physical sector, it spans two physical sectors. The drive must read both, merge the new data, and write both back. Every such write costs two reads and two writes instead of one write, and the penalty applies to every write for the life of the volume, not only to the first.
Queue depth governs how many requests are outstanding at once. A mechanical drive gains little beyond a shallow queue because it serves requests one at a time. A flash device serves many channels in parallel and needs a deep queue to be saturated, which is the practical consequence of the NVMe queue model described above.
Protection at the block layer
Redundancy beneath a volume is provided by mirroring, by parity schemes such as RAID, or by replicating writes to a second system. These operate on blocks. The layer reconstructs the contents of a failed device from the surviving devices and the parity or mirror data, and the volume above continues to present the same addresses.
What the block layer cannot do is distinguish valid data from invalid data. It has no view of files, records or object keys, so it stores a block that an application corrupted, or that ransomware encrypted, with exactly the fidelity it stores an intact one, and replicates it to the second system just as faithfully. Point-in-time recovery at this layer comes from snapshots and from copies taken elsewhere, not from the redundancy scheme.
Integrity checking is likewise partial. A parity scheme detects a device that has failed or returned an error, but a silently corrupted block that the device reports as good is detected only where the system stores and verifies a checksum for each block, and reconciles it on read or during a background scrub.
Block storage and Scality
Scality's platforms present object and file interfaces rather than block volumes. RING provides S3-compatible object storage together with native file access on the same platform. ARTESCA provides S3 object storage for backup and cyber-resilient data protection. Neither exposes a block device to an operating system.
The division follows the workloads. A database's data files, a virtual machine's disk and a boot device require a block volume and the partial-update behaviour it provides. The datasets that reach storage over a network API and are written once and read many times afterwards, including backups, media libraries and the corpora behind analytics and AI workloads, are the ones object platforms are built to hold.