What is Block Storage?

Block storage is storage presented to a computer as a volume of addressable blocks. The host reads or writes data at locations within that volume, much as it would with a disk. A file system or application normally manages how those blocks become files, directories or database records.

The important distinction is the interface. A block storage service provides a disk like address space. It does not normally offer a shared folder interface or an object API. That volume might be backed by a local SSD, a storage array or distributed cloud infrastructure.

For UK broadband users, block storage matters when running a home server, building a virtual machine, hosting an application or diagnosing slow transfers. Storage performance and internet performance can interact, but they are separate constraints. A faster broadband package cannot make every disk operation faster.

This article sits within the Techie Broadband terminology reference and explains the storage layer behind those workloads, including the performance and recovery details that headline capacity figures leave out.

How block storage works

A block device exposes numbered locations, commonly described through logical block addresses. A request specifies where to start and how much data to transfer. The host can update selected regions without asking the storage service to replace an entire named object.

Imagine a server saving a small change to a document. The application works with a file. The file system tracks that file’s name, permissions, length and allocation. It maps the changed file region to storage locations and submits the necessary I/O requests. The storage layer receives those requests rather than a command to save a file called report.docx.

There may be several layers between file and hardware. Partitions, logical volume management, encryption, a hypervisor and a storage controller can each translate or combine addresses. An address seen by the guest operating system need not identify a fixed physical sector on one particular drive.

A volume is not a file system

Creating or attaching a volume makes block capacity available. It does not necessarily create a usable directory. A host may need an appropriate partition layout, file system and mount configuration before ordinary applications can store files there.

Some applications manage a block device directly instead. In that case, the application takes responsibility for the organisation that a general purpose file system would otherwise provide. Block storage does not require every workload to use folders.

An existing volume can already contain data and a file system. Discover its contents before making changes. Formatting is a destructive preparation operation, not a routine cure for a disk that has just appeared.

What does block size mean?

Several different sizes are often called a block. The logical block size is the addressing unit exposed by a device. The physical block size describes an underlying device property. A file system has its own allocation units, while an I/O request can span many addressing units.

For example, a device can expose 512 byte logical sectors while using 4,096 byte physical sectors. A workload might issue 64 KiB requests to that device. Those numbers describe different layers; they are not three competing measurements of the same thing.

Here, KiB means 1,024 bytes, MiB means 1,048,576 bytes and GiB means 1,073,741,824 bytes. KB, MB and GB use decimal units. Keeping those distinctions visible prevents storage and network specifications from being compared incorrectly.

Block storage, file storage and object storage

Choose the interface your application needs before comparing capacity prices. An application expecting a mounted disk, a team accessing shared folders and a service retrieving images by an API have different requirements.

Model	What the client addresses	Who manages file organisation?
Block	Locations within a volume	Host file system or application
File	Files and directories on a share	File service provides the shared namespace
Object	An object identified by a key	Application uses the object API and metadata

With file storage, protocols such as SMB or NFS let clients operate on a shared file namespace. A file service can itself store its data on block devices. These layers can coexist rather than being mutually exclusive hardware categories.

Object storage commonly exposes data through an API using keys, objects and associated metadata. It is a useful comparison when choosing storage for media, backups or application assets, but it does not automatically behave like an attached boot disk.

Block storage is often suitable for operating system volumes and databases that require a conventional disk interface. File storage serves shared folder access. Object storage can suit applications designed around object retrieval. None of those descriptions proves that one product is always faster or safer than another.

Where block storage can live

Local disks and storage arrays

A local SATA or NVMe drive presents a block interface through the host’s storage stack. Its performance depends on the drive, connection, controller, workload and software layers. An SSD and a hard disk can expose the same broad interface while behaving very differently under random access.

A storage area network, or SAN, makes block volumes available across a storage network. A LUN is a logical unit presented by a storage system; it is not necessarily one physical disk. Arrays can assemble a volume from multiple devices and provide their own caching and protection.

iSCSI carries SCSI commands over TCP. Fibre Channel and NVMe based storage arrangements use other mechanisms. A network transport changes the route to the volume, not the fundamental distinction between block access and shared file access.

Cloud volumes and virtual machines

Cloud block services present volumes to compute instances while the provider operates the underlying infrastructure. Amazon EBS and Azure Managed Disks are examples. Their attachment rules, performance controls and lifecycle options are service specific.

Inside a virtual machine, the guest sees a virtual disk. The hypervisor or cloud platform maps that disk to its backing storage. The backing can be a host file, a logical volume or a network service, so a guest disk benchmark also measures part of that surrounding system.

A distributed implementation can even use objects internally while presenting a block interface to clients. Ceph RBD illustrates this layering. What matters to the application is the contract it uses, not a guess about how the provider physically stores every byte.

Location and failure boundaries also matter. A volume that attaches to compute in one availability zone is not automatically attachable everywhere. An architecture should follow the documented service scope rather than assuming the word cloud implies unlimited placement or universal availability.

Block storage at a glance

The infographic summarises the interface and the decisions around it. The host manages the meaning of stored blocks; capacity, performance and recovery remain separate questions.

What determines block storage performance?

The useful question is not simply how fast a disk is. Ask how quickly it completes this application’s requests, with this mix of sizes, reads, writes, concurrency and durability requirements. A large sequential copy and a database waiting on small synchronous writes can stress different limits.

• IOPS measures completed input or output operations per second at a defined measurement layer.

• Throughput measures the amount of data transferred per second.

• Latency measures the time taken for an operation to complete, including relevant waiting.

• Queue depth describes outstanding requests; it is not the same as the number of applications.

• Capacity measures how much data can be held, not how quickly it can be accessed.

Storage throughput is a measured byte rate, just as network throughput describes a measured transfer rate. Neither should be treated as a guarantee that every workload reaches the advertised ceiling.

IOPS figures also need their request size and measurement boundary. Operating systems can merge adjacent requests, and services can split large requests for accounting. Application operations, guest requests and provider counted operations may therefore differ.

AWS documents these distinctions in its EBS I/O characteristics guidance, including how request size, queueing and volume or instance limits affect results. The precise rules belong to that service and should not be assumed for every block product.

Worked example: the IOPS and throughput envelope

Consider a hypothetical volume limited to 10,000 IOPS and 125 MiB/s. Assume fixed request sizes, adequate concurrency and an otherwise unconstrained host and storage path. These are teaching assumptions, not a benchmark or a quoted commercial specification.

The relationship is throughput in bytes per second = completed IOPS × bytes per operation. The workload must stay within both the operation ceiling and the byte ceiling. Converting KiB to MiB means dividing by 1,024.

Request size	10,000 IOPS would transfer	Limit from the 125 MiB/s ceiling
4 KiB	39.0625 MiB/s	32,000 IOPS; the 10,000 IOPS limit binds
16 KiB	156.25 MiB/s	8,000 IOPS
256 KiB	2,500 MiB/s	500 IOPS

For the 16 KiB row, 125 × 1,024 ÷ 16 = 8,000 operations per second. Provisioning a higher IOPS ceiling alone would not increase this workload’s maximum transfer rate while its 125 MiB/s limit remained unchanged.

For the 4 KiB row, the operation ceiling binds first. Increasing only the byte throughput allowance would not make 10,000 completed 4 KiB operations carry more than 39.0625 MiB each second.

Actual results can be lower because the host, controller, transport, CPU, file system or application imposes another limit. These calculations describe an upper envelope under stated assumptions, not an expected speed for an unspecified disk.

Latency and concurrency change the picture

An application that issues one request and waits for completion before issuing the next cannot exploit unlimited parallelism. If each complete operation takes 1 ms, the ideal serial ceiling is 1 ÷ 0.001 = 1,000 IOPS. At 20 ms it is 50 IOPS.

With 4 KiB per operation, that 20 ms serial example carries 200 KiB/s. A path with generous bandwidth can therefore deliver very little data when each dependent small request must wait. This is an illustrative operation latency, not a claim that internet ping directly measures disk completion time.

Additional outstanding requests can let a system use parallel resources. Under stable conditions, average outstanding work is related to completion rate and average time in the system. Eight average outstanding requests at 2 ms average completion time imply about 4,000 IOPS. A configured queue limit of eight does not prove that eight requests are continuously outstanding.

Concurrency eventually encounters a bottleneck. More queueing beyond that point can increase response time without improving useful throughput. Average latency can also hide slow outliers, so an application with strict response requirements should examine latency percentiles as well as averages.

A completed write is not always a durable write

An application can hand data to an operating system cache before the final storage action finishes. A storage device can also acknowledge a write held in a volatile cache. An apparently fast save is therefore not, by itself, evidence that the data will survive a power interruption.

The Linux kernel’s write cache documentation explains forced flushes and Force Unit Access as mechanisms for reaching nonvolatile storage. File systems and drivers must carry the required durability operations through the stack.

For a database or similar workload, distinguish buffered write acceptance from the application’s durable commit. The relevant behaviour depends on its configuration and the entire storage system. A performance test that omits required flushes can answer a different question from the production workload.

When does broadband affect block storage?

Start by tracing where the data actually travels. A cloud VM writing to its attached cloud volume normally uses the provider’s storage path. Your UK home broadband connection can carry administration traffic without carrying each disk I/O.

By contrast, copying data from that VM to your home computer uses the internet path. A home server uploading a backup uses your upstream connection. A remotely presented block device may put network delay directly into storage operations, depending on the architecture.

Network latency affects the round trip between endpoints. Storage completion latency also includes software, queueing and device work. Adding those layers together is more useful than treating a broadband speed test as a disk benchmark.

Why a gigabit connection and 125 MiB/s differ

A decimal 1 Gbps link carries at most 1,000,000,000 ÷ 8 = 125,000,000 bytes per second before relevant overheads. That is 125 MB/s, or approximately 119.21 MiB/s.

A storage rate of 125 MiB/s represents 131,072,000 bytes per second, equivalent to 1.048576 Gbps of payload bits. Even an ideal decimal gigabit link cannot carry that payload rate. Ethernet and higher layer overheads reduce usable transfer capacity further.

For UK FTTP and FTTC users, check the upstream and downstream rates separately. A package’s download headline does not establish its upload capability. During a transfer, WiFi, router processing, negotiated Ethernet speed, competing traffic and the remote endpoint can add their own constraints.

Worked example: exporting 100 GB

Suppose exactly 100 GB of data must cross a connection, using decimal GB, with no compression and a constant payload rate. This is an ideal transfer calculation: time in seconds = 100,000,000,000 × 8 ÷ bits per second.

Payload rate	Calculated duration	Relevant interpretation
20 Mbps	40,000 seconds; 11 h 6 min 40 s	An illustrative constrained upload
100 Mbps	8,000 seconds; 2 h 13 min 20 s	A faster transfer path
1 Gbps	800 seconds; 13 min 20 s	An ideal payload rate, not a retail promise

Real transfers take longer when usable throughput is lower or they pause for processing. A 100 GB volume does not imply a backup uploads 100 GB every time: used data, changed blocks, compression, deduplication and the backup method determine the bytes transferred.

If a large download reaches the computer quickly but then slows while writing to disk, inspect both sides. A storage bottleneck is plausible, but so are exhausted buffers, CPU work or application behaviour. Establish which resource is constrained before buying a faster broadband package.

Snapshots, backups and recovery

A snapshot records a point in time view of a volume under a service’s consistency rules. It can help create another volume or restore an earlier state. The capture process does not automatically know which database transaction the application considers complete.

AWS’s EBS snapshot guidance states that snapshots capture written volume data and exclude data still cached by the application or operating system. It describes pausing writes or unmounting where appropriate to improve consistency. Those steps depend on the workload and should be planned rather than applied blindly to a running service.

A crash consistent snapshot can resemble the disk state after an abrupt stop. The file system or database may need recovery when it starts. An application consistent capture coordinates the relevant application state, flushes and timing. Coordinating multiple volumes does not, by itself, prove application consistency.

Snapshots are one recovery mechanism. They become useful protection through a retention policy, suitable isolation, recoverable keys and tested restoration. Replication and RAID address other failure scenarios; neither prevents a legitimate deletion or incorrect application update from reaching the protected storage.

1. Identify which volumes, application records and configuration form one recoverable service.

2. Choose a capture method compatible with the application’s consistency requirements.

3. Keep recovery copies with permissions and retention appropriate to the failure scenarios.

4. Restore into a suitable isolated environment and check the actual application data.

5. Measure recovery time and document the steps needed to resume service.

A volume recreated from a snapshot can have different initial performance from a fully prepared volume. Some cloud services initialise data on first access or offer preparation options. Check the provider’s documented restore behaviour before treating the first read benchmark as normal steady performance.

Can several computers share one block volume?

Some services allow a volume to attach to several hosts. Attachment is a connection capability; it is not a shared file system or a locking scheme. Multiple independent hosts must coordinate ownership of data and metadata.

For example, AWS warns against ordinary simultaneous shared access with common file systems such as ext4 and XFS on Multi Attach volumes. A suitable clustered file system or application coordination is required for supported shared access.

A properly designed cluster also deals with hosts that lose contact or fail. Fencing prevents an old owner from continuing writes when another host takes over. If the requirement is simply shared files for several computers, a file service is often the more appropriate interface.

Capacity, growth and deletion

Volume size, partition size and file system size are separate measurements. Increasing a cloud volume can leave the existing partition or file system unchanged until the appropriate guest operations are completed.

For an illustrative units comparison, 100 GiB equals 107.3741824 GB. A display using decimal GB and another using binary GiB can report different numbers for the same bytes. File system metadata, reserved space and existing data create further differences between raw capacity and available file space.

Thin provisioning allocates backing space as data is written rather than necessarily dedicating all advertised logical capacity immediately. The backing system still needs sufficient real capacity. A thin volume’s logical size does not establish how much free physical space remains in a shared pool.

Deleting a file frees its allocation in the file system. It may not immediately release backing storage or reduce a bill. Discard mechanisms such as TRIM or UNMAP can communicate unused regions where every relevant layer supports them; retained snapshots can still reference older data.

Persistent means storage can outlive a particular compute lifecycle under documented rules. It does not mean undeletable. Check whether terminating an instance deletes an associated volume, and distinguish persistent volumes from local instance storage whose lifetime can be tied to the host.

Cost and security considerations

A useful cost comparison includes provisioned capacity, additional performance allowances, retained snapshots, recovery copies and any applicable transfer charges. An idle allocated volume can still cost money. Exact charging rules and prices depend on the product and should be checked against its current terms.

At rest encryption protects stored bytes under its key arrangements; it does not replace host access controls, application permissions or secure transport. Confirm who can attach, snapshot, restore or delete a volume, and who can use or administer its encryption keys.

Recovery also depends on those keys. A retained encrypted snapshot is not sufficient if the required key is no longer usable. For UK organisations, storage region selection is only one part of assessing access, replication and data handling requirements.

How to investigate slow block storage

Begin with observations from the real workload. Determine whether the delay appears during reads, writes, durable commits, startup, snapshot restoration or a network copy. Record the time period so application logs, host metrics and provider graphs can be compared.

1. Map the path from application to file system, guest disk, host or cloud volume and backing service.

2. Check free file space and inodes, volume health, error logs and any recent size or configuration change.

3. Observe request size, read and write rates, queueing and completion latency during the slowdown.

4. Compare volume allowances with aggregate host or instance limits and any burst behaviour.

5. Separate cache effects and restore preparation from sustained storage behaviour.

6. If data crosses broadband, repeat a controlled wired transfer and inspect both network directions.

7. Change the identified constraint, then repeat the same workload with the same measurement boundary.

Read only Linux observations

On a Linux host, lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS lists device relationships and file system information without formatting anything. Compare it with df -hT for mounted file system capacity and df -i for inode usage. Names and available columns depend on the installed utilities and environment.

If the sysstat tools are installed, iostat -xz 1 5 displays extended device statistics at one second intervals for five reports. Its initial report normally covers time since startup, so interpret subsequent interval reports separately. Reading these statistics does not run a synthetic write test.

The await field includes queueing and servicing time, while aqu-sz reports average outstanding queue length. Read and write rates describe completed device traffic at that observed layer. A high %util is not a universal proof that a modern SSD or parallel array has exhausted its capacity.

Keep guest and provider measurements distinct, and correlate them with application delay. A low storage rate can mean the application is waiting on something else rather than proving that the volume is defective.

How to read a benchmark responsibly

A useful benchmark states request size, read and write mix, sequential or random access, concurrency, test duration, dataset size, cache behaviour and durability settings. It also identifies the host and volume configuration and whether results describe a guest, physical device or service metric.

Use a disposable volume or an appropriate test file for synthetic tests. Writing directly to a populated block device can overwrite data. A small cached test, a brief burst and a large sustained workload answer different questions, so compare like with like.

A speed test between your home and an internet server measures that network transfer path. It does not establish the IOPS capability of a cloud volume. A local disk benchmark likewise cannot establish the internet rate available to a remote user.

When is block storage the right choice?

Requirement	Useful starting point	What to verify
Boot a VM or run a disk based database	Block volume	Latency, durability, attachment and recovery
Share folders between computers	File service	Protocol, permissions and concurrent access
Store API accessible media or backup objects	Object service	API compatibility, retrieval and lifecycle
Serve temporary compute scratch data	Local or temporary storage	Loss conditions and reproducibility

For a UK home lab, an SSD can improve storage limited workloads while leaving an upload limited offsite backup unchanged. For a cloud application, a higher performance volume may help a constrained database while the website remains limited by application CPU or network delivery.

The practical decision is to match the interface and failure model first, then measure the workload and its complete path. Capacity tells you how much fits. It does not tell you how quickly the application works or whether you can recover it.

Frequently asked questions

Is block storage the same as an SSD?

No. Block storage describes an access model. An SSD is a storage technology that can provide that model. A block volume can also be backed by hard disks or distributed infrastructure.

Does block storage contain files?

It can contain the data and metadata of a file system, but the block interface does not normally manage a named file namespace for the client. The host file system or application interprets the stored regions.

Is block storage always faster than object storage?

No. Performance depends on implementation, workload, request size, concurrency and the complete path. A poorly matched block volume can perform worse for a task than an appropriately designed object service.

Does a larger volume always have more IOPS?

No. Some products couple performance to capacity and others allow separate performance settings. The current service specification, host limits and workload determine the useful result.

Can I use a snapshot as my only backup?

A snapshot can be part of a backup plan, but its name alone proves neither isolation nor recoverability. Check consistency, retention, deletion permissions, key access and a tested restore against the failures you need to survive.

Will faster broadband improve my cloud disk?

It can help transfers that cross your connection. It normally does not change the storage path between a cloud VM and its attached cloud volume. Identify where the bytes travel and where the application waits.