Storage Block Sizes and the blockdev Command

1. Introduction

When it comes to storage, a block is the minimum unit we can allocate or address. However, what this actually means depends on a number of involved actors and systems:

• storage medium
• filesystem
• kernel

Since the synchronization between these isn’t always straightforward, we may have to check each level individually.

In this tutorial, we understand storage block sizing and get into ways to influence it. First, we go over block sizes on different levels. After that, we explore a common command to work with the size of a block at each one.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.

2. Block Size

Blocks are the minimal units that we can allocate and address. Storage blocks are a convenient, but fairly misleading and not strictly determined concept.

2.1. Storage Units

To begin with, let’s define some units:

+----------+------+----------+
| Name     | Unit | Value    |
+----------+------+----------+
| Bit      | b    | 1 / 0    |
| Byte     | B    | 8 b      |
+----------+------+----------+
| Kilobyte | KB   | 1000 B   |
| Kibibyte | KiB  | 1024 B   |
+----------+------+----------+
| Megabyte | MB   | 1000 KB  |
| Mebibyte | MiB  | 1024 KiB |
+----------+------+----------+
| Gigabyte | GB   | 1000 MB  |
| Gibibyte | GiB  | 1024 MiB |
+----------+------+----------+
| Terabyte | TB   | 1000 GB  |
| Tibibyte | TiB  | 1024 GiB |
+----------+------+----------+
| Petabyte | PB   | 1000 TB  |
| Pebibyte | PiB  | 1024 TiB |
+----------+------+----------+
| Exabyte  | EB   | 1000 PB  |
| Exbibyte | EiB  | 1024 PiB |
+----------+------+----------+

Although similar, one unit type is set in terms of the SI powers of 10 but the other uses powers of 2 for technical reasons. Still, the latter may be harder to comprehend by humans. Also, while the difference between KB and KiB can be an ignorable 2-3%, EB and EiB differ by more than 15% per unit.

If omitted, the unit is usually [B]ytes.

2.2. Storage Medium Block

Physical mediums have a built-in minimal unit enforced by their controller.

For instance, a modern solid-state drive (SSD) may report a logical block size of 512B. This comes from older technology, i.e., a hard disk drive (HDD) has 512B sectors. Yet, the actual standard minimal unit for an SSD is now 4KiB:

$ fdisk --list /dev/sda
Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
[...]

In this case, fdisk [–list]s information about /dev/sda, where we can see the sector size in relation to the physical block. Importantly, special configurations such as RAID may impose different settings.

So, the discrepancy between the reported logical block size and the actual controller block size means that the system requests 512B chunks but the physical medium reads a 4KiB block to extract 512B sector-sized information. Although this may be a waste in many cases, a request for the next 512B chunk wouldn’t trigger further storage operations due to buffering.

2.3. Filesystem Block

When it comes to filesystems, the block size in terms of minimal allocation unit can also be called a cluster.

This is specified when formatting:

$ mke2fs -t ext4 -b 4096 /dev/sdx1

Here, we use mke2fs to format /dev/sdx1 with the ext4 filesystem with a [-b]lock size of 4096B. If we don’t explicitly add a block or [-c]luster size, mke2fs checks with its ruleset in /etc/mke2fs.conf:

$ cat /etc/mke2fs.conf
[defaults]
      base_features = sparse_super,large_file,filetype,resize_inode,dir_index,ext_attr
      default_mntopts = acl,user_xattr
      enable_periodic_fsck = 0
      blocksize = 4096
      inode_size = 256
      inode_ratio = 16384

[fs_types]
      ext3 = {
              features = has_journal
      }
      ext4 = {
              features = has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize
      }
      small = {
              blocksize = 1024
              inode_ratio = 4096
      }
      floppy = {
              blocksize = 1024
              inode_ratio = 8192
      }
      big = {
              inode_ratio = 32768
      }
[...]

Here, we can see some defaults, as well as specific features per filesystem type. Further down, we can also see sizing information. The final block size depends on the filesystem type, expected usage as specified by the mke2fs -T option, as well as the size of the formatted partition. Importantly, the block size must be a power of 2.

Let’s check the block size of our current root partition:

$ tune2fs -l /dev/sda1
[...]
Block size:               4096
[...]

As expected, we have an overlap between the block size we get for the filesystem as reported by tune2fs and the storage medium block size. This isn’t a requirement but is usually the case for better performance on many systems.

2.4. Kernel Block

Regardless of the physical and filesystem specifications and limitations, the operating system (OS) kernel can request any amount of information at any time.

Still, the OS usually has different mechanisms to optimize its storage reads. Most notably, information transfers between the RAM cache and secondary storage commonly happen in pages. On the other hand, the read() system call can request any size but the minimum will always depend on the hardware, controller, and filesystem.

3. Using blockdev

As we already saw, storage block sizes mainly exist on two levels:

• physical storage medium: physical and logical
• virtual partition filesystem: block and cluster

Thus, having a way to check and change these settings may be beneficial. In particular, we can use the blockdev command.

It’s good practice to use –rereadpt to reread the partition table before checking data for a given partition.

3.1. General Device Information

To begin with, blockdev can tell us about the size and structure of the hardware device we have:

• –getsize64: size in bytes
• –getsz: size in 512B sectors
• –getdiscardzeroes: check whether zeroes are ignored
• –getalignoff: alignment offset in bytes

Let’s try it out:

$ blockdev --getsize64 /dev/sda
34359738368

This information overlaps with our earlier fdisk dump of /dev/sda.

3.2. Get Block Information

Of course, blockdev also offers several flags to specifically check the current block size information:

• –getss: logical block size
• –getpbsz: physical block size
• –getiomin: smallest chunk per storage operation
• –getioopt: optimal chunk per storage operation
• –getmaxsect: max sectors per request
• –getbsz: block size

Let’s confirm our values for the logical and physical sizes of a /dev/sda block:

$ blockdev --getss /dev/sda1
512
$ blockdev --getpbsz /dev/sda1
4096

As expected, we get the same block sizes. Since the physical medium and its controller handle 4096B blocks, the minimum we can exchange between it and RAM is that amount of bytes, not 512B:

$ blockdev --getiomin /dev/sda
4096

Of course, that also means that the current –getbsz block size is also 4096B.

3.3. Readahead Sectors

Usually and on average, many of the read and write operations over a given medium are sequential. In other words, if we read or write position X, we expect that position X+1 will be the next one read or written.

This situation is so prevalent that there is a so-called readahead feature that automatically gets a number of following storage blocks or sectors before they are requested. So, several options enable us to set and get this number on different levels:

• –setra: set number of readahead sectors
• –getra: get number of readahead sectors
• –setfra: set number of filesystem readahead sectors
• –getfra: get number of filesystem readahead sectors

While the first two options work with the storage medium, the latter two relate to the filesystem.

3.4. Buffering

Buffering is part of the readahead and caching strategy. In short, it’s a way to copy data that we expect to need shortly from secondary storage to main memory. However, we may sometimes want to drop the buffered data, so we can use –flushbufs to flush the buffers:

$ blockdev --flushbufs /dev/sda1

Naturally, buffering exists on many levels, so a complete buffer flush might require more commands.

Importantly, if we clear the buffers, we can ensure the next request for a read operation would actually cause a block to be read instead of pulling data from the cache.

4. Summary

In this article, we delved into block sizes and how to manipulate them.

In conclusion, although the storage block size can be a bit misleading, having a grasp of each related system can help troubleshoot and optimize it.