Block storage is a storage model in which data is stored and accessed as fixed-size blocks on a raw volume, each addressed by its position, without any built-in notion of files or folders. In servers and server storage, it describes local disks, SAN volumes and cloud volumes that the operating system sees as a disk and formats with its own file system.
Because the server controls the file system directly, block storage offers the lowest latency and the most predictable performance of the main storage models. It is the standard foundation for operating system disks, databases and virtual machine images.
How block storage works
A block device exposes a linear array of logical blocks, usually 512 bytes or 4096 bytes each, numbered by logical block address (LBA). The host issues read and write commands for ranges of LBAs, and the device returns or stores exactly those blocks. It has no knowledge of what the blocks contain.
Structure is added by the host. The operating system creates partitions, often groups disks with RAID or LVM, and formats the result with a file system such as ext4, XFS, NTFS or ZFS. Databases may even manage raw block devices themselves to control caching and write ordering.
Block storage can be local or networked. A local NVMe drive and a SAN volume both appear to the server as a block device, but the network path adds latency and new failure modes.
Between the physical media and the file system, a storage virtualization layer often sits in the middle. A storage array or software-defined system pools many drives, protects them with RAID or erasure coding, and carves out logical volumes, often called LUNs, that are thin-provisioned. A thin volume reports its full size to the host but consumes physical space only as data is written, which saves capacity but requires monitoring of real pool usage to avoid running out of space unexpectedly.
Block, file and object storage compared
Block storage is one of three main storage models. They differ in what unit the client works with and who manages the metadata.
| Model | Unit of access | Metadata managed by | Typical use |
|---|---|---|---|
| Block storage | Fixed-size blocks by address | The host file system | Boot disks, databases, VM disks |
| File storage | Files and directories | The storage server, such as a NAS | Shared folders, home directories |
| Object storage | Whole objects by key over HTTP | The object store | Backups, media, static assets, data lakes |
The decisive difference is sharing. A NAS share can be mounted by many servers at once, because the NAS coordinates file access. A block volume is normally attached to one server at a time; attaching it to two hosts with an ordinary file system corrupts data, unless a cluster file system coordinates the access.
Protocols and delivery options
Networked block storage reaches servers through block-level protocols that carry SCSI or NVMe commands. The protocol determines latency, required hardware and cost.
| Protocol | Transport | Typical latency | Typical setting |
|---|---|---|---|
| Local SATA or SAS | Direct cable | About 0.1 ms on SSDs | Servers with internal drives |
| Local NVMe | PCIe | Tens of microseconds | High-performance servers |
| iSCSI | TCP over Ethernet | About 0.2 to 1 ms | Small and mid-size SANs |
| Fibre Channel | Dedicated FC fabric | Below 0.5 ms | Enterprise SANs |
| NVMe over Fabrics | RDMA or TCP | Close to local NVMe | Modern all-flash arrays |
| Cloud block volume | Provider network | About 0.5 to 2 ms | Virtual machines in public clouds |
Cloud block volumes are replicated within one availability zone and can be detached from one virtual machine and attached to another. They are durable, but they do not replace backups, because deletion and corruption are replicated as faithfully as valid data.
Performance parameters of block storage
Block storage performance is described by three related numbers: IOPS, throughput and latency. They depend on block size, queue depth and access pattern, so a single number is never the whole picture.
| Metric | Meaning | What drives it |
|---|---|---|
| IOPS | Input and output operations per second | Small random I/O, such as databases |
| Throughput | Megabytes per second transferred | Large sequential I/O, such as backups and video |
| Latency | Time to complete one operation | Media type, network path, queue depth |
| Queue depth | Outstanding operations in flight | Application parallelism |
As a rough guide, a 7,200 rpm hard disk delivers about 75 to 150 random IOPS, a SATA SSD tens of thousands, and an enterprise NVMe drive hundreds of thousands. Cloud volumes often cap IOPS and throughput per volume, so a provisioned limit can become the bottleneck long before the underlying hardware does.
Choosing and managing block volumes
Block storage is the right choice when an application needs a private, low-latency disk with full file system control. It is the wrong choice for data that many servers must read and write at once, or for large archives accessed rarely.
- Use block storage for operating system disks, relational databases, message queues and virtual machine images.
- Use file storage when several servers must share the same files.
- Use object storage for backups, logs and static content at large scale and low cost per gigabyte.
- Take consistent snapshots by flushing or freezing the file system, otherwise database snapshots may not be restorable.
- Align partitions and file systems to 4 KiB or larger boundaries to avoid extra read-modify-write cycles.
Growing a volume is usually easy, but it is a two-step operation: the volume is enlarged first, and then the partition and file system must be extended. Shrinking is much harder and with some file systems, such as XFS, not possible at all.
The simple explanation
Block storage works like an empty notebook with numbered pages. The storage only knows how to write or read page number 512 or page number 9,000. It does not know what is written there.
The server decides how to organize the notebook. It adds a table of contents, chapters and file names. Because the server is in full control, reading and writing is very fast and predictable. The downside is that only one reader can safely use the notebook at a time.
How it is used in practice
An online booking platform runs its PostgreSQL database on a cloud virtual machine. The data lives on a 500 GB block volume separate from the boot disk, formatted with XFS and mounted at the database data directory.
As bookings grow, query latency rises during peaks. Monitoring shows the volume constantly hitting its provisioned limit of 3,000 IOPS. The team switches the volume to a higher performance tier with 12,000 IOPS without reattaching it, and latency drops back to normal. They also schedule nightly snapshots after a short database checkpoint, which allows a full restore within minutes when a faulty migration later deletes a table.