How to Benchmark Hard Disk Physical Geometry with fio on Linux 2025

Understanding your hard disk's physical geometry—including sector size, track layout, and cluster alignment—is crucial for storage optimization, performance tuning, and troubleshooting I/O bottlenecks. While modern operating systems abstract away these details, developers working with databases, virtualization, and high-performance storage systems need to understand the underlying hardware characteristics.

This guide shows you how to use microbenchmarking with fio (Flexible I/O Tester) and sequential read patterns to reverse-engineer your disk's physical geometry without vendor documentation.

Why Disk Geometry Matters for Developers

Modern hard drives present a logical block size (usually 4096 bytes) to the OS, but internally store data in physical sectors. Misalignment between logical partitions and physical sectors can degrade performance by 10-50%. This becomes critical when:

• Setting up virtual machine datastores on raw disks
• Optimizing database page sizes for SSD/HDD mixed environments
• Configuring RAID stripe sizes
• Troubleshooting unexplained I/O performance degradation
• Working with container storage drivers that depend on block alignment

Understanding Microbenchmarking Patterns

Microbenchmarking exploits the fact that sequential reads exhibit different performance characteristics depending on physical disk geometry. When a read request spans a track boundary, the disk must seek to the next track, introducing latency. By analyzing read latency patterns across different block sizes and offsets, you can infer:

• Track size: The number of sectors per track
• Sector size: Physical sector boundaries
• Cache behavior: Internal disk cache patterns
• Head movement characteristics: Seek time penalties

Prerequisites

Before starting, ensure you have:

• fio installed (sudo apt-get install fio on Ubuntu/Debian)
• Raw disk access permissions (typically requires root or sudo)
• A test disk or partition you can afford to read from extensively
• The disk's vendor specifications (optional but helpful for comparison)

Step-by-Step: Creating Your Geometry Benchmark

Step 1: Identify Your Target Disk

lsblk
hdparm -I /dev/sdX

Note the device name (e.g., /dev/sda) and note any advertised logical/physical sector sizes.

Step 2: Create a Sequential Read Benchmark with Variable Block Sizes

Create a file named disk-geometry-bench.fio:

[global]
ioengine=libaio
iodepth=1
rw=read
bs=4k
runtime=30s
time_based
group_reporting

[sequential-4k]
filename=/dev/sdX
bs=4k
size=100m
offset=10g

[sequential-8k]
filename=/dev/sdX
bs=8k
size=100m
offset=10g

[sequential-16k]
filename=/dev/sdX
bs=16k
size=100m
offset=10g

[sequential-32k]
filename=/dev/sdX
bs=32k
size=100m
offset=10g

[sequential-64k]
filename=/dev/sdX
bs=64k
size=100m
offset=10g

Replace /dev/sdX with your actual device name.

Step 3: Run the Benchmark with Latency Tracking

sudo fio disk-geometry-bench.fio --output=bench-results.txt --output-format=normal

For more detailed latency histograms:

sudo fio disk-geometry-bench.fio --latency-log=bench --write_lat_log --clat_percentiles=1

Step 4: Analyze Throughput Patterns

Examine the throughput results across different block sizes:

grep -A5 "sequential-" bench-results.txt | grep -E "read|bw="

Look for "knee points" where throughput jumps significantly—these often correspond to physical track boundaries.

Interpreting Results: A Practical Example

| Block Size | Sequential Read Speed | Latency (us) | Performance | |-----------|----------------------|--------------|-------------| | 4 KB | 85 MB/s | 450 | Baseline | | 8 KB | 125 MB/s | 380 | +47% | | 16 KB | 180 MB/s | 290 | +112% | | 32 KB | 220 MB/s | 220 | +159% | | 64 KB | 225 MB/s | 215 | +165% |

In this example, the significant jump from 8 KB to 16 KB suggests the physical track size is likely between 8 KB and 16 KB. The plateau at 64 KB indicates you've likely exceeded one track's worth of data.

Advanced: Track Boundary Detection

For finer-grained geometry discovery, test with randomized offsets:

[global]
ioengine=libaio
iodepth=1
rw=read
runtime=10s
time_based
bs=4k
random_distribution=uniform:0-100m

[random-boundary-test]
filename=/dev/sdX
rw=randread
offset=10g
size=100m

Run this multiple times with different offsets (offset=10g, offset=11g, etc.) and compare latency patterns. Sudden latency increases at specific offsets indicate track boundaries.

Common Pitfalls and Solutions

Problem: Permission Denied errors

sudo usermod -aG disk $USER
# Log out and back in

Problem: Inconsistent results

• Clear disk caches first: sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
• Disable turbo boost for consistent measurements: echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo
• Run tests multiple times and average results

Problem: Can't access physical device directly

• Use a partition instead: /dev/sdX1 (results will still reveal geometry)
• Ensure the partition is unmounted during benchmarking

Validating Against Specifications

Once you've estimated geometry, cross-reference with your drive's specs:

hdparm -I /dev/sdX | grep -i sector
sudo smartctl -a /dev/sdX | grep -i "sector\|rotation"

For NVMe drives:

nvme id-ns /dev/nvmeXnY | grep -E "lba|sector"

Tools and Resources

While fio is industry-standard, complementary tools provide additional insights:

• iostat: Monitor I/O patterns during benchmarks
• blktrace: Capture kernel block I/O events
• sysbench: Simple disk benchmarking alternative
• diskstat: Parse /proc/diskstats for detailed metrics

Performance Implications for Production

Understanding geometry helps you:

1. Align partitions correctly: Use parted or fdisk with geometry awareness
2. Optimize database parameters: Set innodb_page_size to match physical tracks
3. Configure RAID properly: Stripe size should align with physical geometry
4. Troubleshoot cache issues: Identify when workloads exceed track cache

Conclusion

Microbenchmarking with fio reveals hard disk physical geometry without needing vendor documentation. By analyzing sequential read patterns across different block sizes and offsets, developers can optimize storage configurations for their specific hardware. This approach is particularly valuable in on-premises environments where hardware varies and official specifications may be outdated or unavailable.

Regularly benchmark your storage infrastructure—geometry-based optimizations can provide consistent 10-30% throughput improvements with no hardware changes.