FIO `fsync` Storage Benchmark Analysis

Linux I/O Performance Engineering Benchmarking Storage Systems

1. Purpose of the Test

The fsync benchmark measures how quickly a block storage system can durably persist data from volatility (RAM buffer caches) directly onto non-volatile hardware (Flash memory cells or magnetic platters).

Standard operating system writes are cached in RAM immediately for high performance. However, databases like Prometheus, SQLite, PostgreSQL, and Docker storage engines issue explicit fsync() syscalls to guarantee that transaction records (such as Write-Ahead Logs) survive sudden power loss. This test exposes true hardware latency by forcing a flush on every transaction.

2. Benchmark Execution & Workflow Sequence

The sequence diagram below shows how fio interacts with the OS VFS and physical Flash storage controller during an fsync=1 test execution cycle:

FIO Process

Linux Kernel (VFS)

Storage Device

FIO

1. write(4KB block)

VFS

2. Buffer in PageCache

Storage

FIO

3. sys_fsync() forced

VFS

4. Flush command (SYNCHRONIZE CACHE)

Storage

5. Physical write ack to NAND

VFS

6. fsync() returns control

FIO

3. Parameter Breakdown

fio --name=fsync_test \
    --filename=testfile.tmp \
    --size=500M \
    --rw=randwrite \
    --bs=4k \
    --fsync=1 \
    --ioengine=sync \
    --runtime=30 \
    --time_based \
    --group_reporting

Flag	Technical Purpose
`--rw=randwrite`	Simulates realistic database workloads by writing non-contiguous 4KB blocks across the file.
`--bs=4k`	Sets the block size to 4 kilobytes—the standard page size for Linux kernel allocation and time-series DB chunks.
`--fsync=1`	Forces the kernel to issue an `fsync` system call after every single block write.
`--ioengine=sync`	Uses standard synchronous read/write operations, blocking execution until the OS accepts the completion call.

4. Performance Metrics Evaluation

Key metrics collected during an execution and how they evaluate underlying storage hardware performance:

IOPS (Input/Output Operations Per Second): Higher is better. Indicates how many individual persisted writes the controller can complete each second under strict flush constraints.
Average Sync Latency (sync avg): Lower is better. Measures the real-world overhead added to a application thread when persisting data to disk.
99.99th Percentile Tail Latency: The critical metric for reliability. High values (e.g., >300ms) indicate that internal wear-leveling or Garbage Collection on Flash storage (like MicroSD controllers) causes severe temporary stalls.