Skip to content
WindowsDeep Dive Published Updated 4 min readViews unavailable

Windows DiskSpd: Design a Bounded File-Target Storage Test

Build repeatable DiskSpd workloads against a disposable file, interpret concurrency and latency settings, and avoid raw-device writes or misleading comparisons.

DiskSpd is Microsoft’s storage load generator. It can exercise a regular file, a partition, or a physical device, and those targets answer different questions. For a first diagnostic, use a new, disposable file on a deliberately selected scratch volume. A file target exercises the filesystem and storage stack together. A raw-device target bypasses that context and can destroy data; a write workload will not stop to ask whether the target is important.

Microsoft’s repository currently identifies DiskSpd 2.3 as the current release. Record the executable version and Windows build with every result. DiskSpd 2.3 changed default thread placement on heterogeneous P-core/E-core systems and buffer separation, so comparisons against earlier builds may need a new baseline.

Define a workload before selecting flags

Translate the question into four explicit choices:

  1. Block size and access pattern: -b4K -r models aligned, random 4 KiB requests; a sequential workload uses -s instead.
  2. Concurrency: -t sets threads per target and -o sets outstanding I/O requests per thread. Two threads with four outstanding requests each can issue up to eight requests to one target.
  3. Read/write mix: -w20 asks for a 20% write workload and 80% reads. The result is a long-run randomized mix, not an exact per-window quota.
  4. Measurement window: -W10 warms the test for ten seconds before measurement; -d60 measures for sixty seconds; -L requests latency statistics.

Keep those settings constant when comparing storage paths. Start with modest concurrency and increase it only when the workload you are trying to represent justifies it. High queue depth can improve throughput while making latency much worse for interactive or shared workloads.

Run only against a fresh test file

First choose a non-production scratch volume with enough free space and create a dedicated directory. Use a filename that does not already exist; -c creates or recreates its target file. This example writes only inside that disposable file:

$target = 'D:\DiskSpd-Lab\run-2026-10-14-4k.dat'
if (Test-Path -LiteralPath $target) {
    throw 'Choose a fresh disposable filename; DiskSpd -c recreates the target.'
}

diskspd.exe -c8G -b4K -r -t2 -o4 -w20 -W10 -d60 -L -Sh $target

D:\DiskSpd-Lab is a placeholder: create it only after confirming that D: is the intended scratch volume. The command allocates an 8 GiB test file and issues a mixed random workload to that path. It does not select a physical disk by number. The write portion still changes the scratch file, so do not point it at a real data file or a directory used by another workload.

DiskSpd can use SetFileValidData to prepare a created file quickly when the caller has SeManageVolumePrivilege. Microsoft warns that this fast path can expose previously written but logically deleted storage contents through the new file. Prefer a standard, non-elevated token without that privilege for a scratch-file test; the slower initialization path writes through the file and may take longer. If the tool reports that slower path, treat the preparation time as setup, not measured workload time. If an elevated run is unavoidable, first evaluate Microsoft’s warning and the storage system’s deleted-data protections.

The -Sh option is equivalent to disabling software caching and enabling write-through. That can be useful for a specific storage-path question, but it is not a universal setting for every application workload. Run a separate, clearly labelled buffered test if application behavior depends on the Windows cache; do not compare the two as though they were the same workload.

Preserve enough context to reproduce the result

Save the full command line, DiskSpd version, OS build, filesystem, volume type, target file size, storage/controller path, power state, and text or XML output. Run tests in a maintenance window if sustained I/O could affect users. Repeat comparable runs after the system reaches a stable temperature and load; do not mix a cold first run with warmed repeats without labeling the difference.

Use throughput and IOPS together with latency statistics. Higher throughput does not prove a faster application if request latency or queueing worsened. A file-target benchmark also includes filesystem behavior, filter drivers, encryption, virtualization, cache policy, and the underlying storage device. If the result is surprising, pair it with a bounded WPR/WPA trace and Windows performance counters instead of changing storage policy based on one headline number.

Never substitute #PhysicalDiskId or a drive-letter partition for the test-file path in a write workload. DiskSpd’s own documentation says a write test destroys existing data without a warning, and recommends special handling before device-target writes. After saving the output, remove only the exact disposable filename you created; do not clean up with a wildcard.

Related:

Sources:

Comments