How to Measure a Storage Workload Before Requesting Quotes

Before asking suppliers to size storage, measure what the host reads and writes during real operation. Record daily host-write volume, shorter peaks, read/write mix and the periods that create them. Attach the exact device, software and measurement conditions. If request sizes, tail latency or application time limits are unknown, say so; a guessed “typical 4K workload” can send qualification in the wrong direction.

This guide is the engineering input to an RFQ. The full flash-storage RFQ guide covers supplier comparison and commercial terms separately.

Choose representative measurement windows

Start with the storage role: boot disk, application database, event log, camera recorder or removable transfer medium. Measure at least normal operation and the most demanding known phase, such as startup, data import, update, recovery or backup. Record when each phase begins and ends, which applications run and how full the device is. A 24-hour total is useful for daily writes, but a short high-rate burst can disappear in that average.

Take repeated observations on the same whole device. On a system with several disks, identify the one being qualified; a system-wide sum is not a per-device workload. Counter differences divided by elapsed time give an interval average. Shorter intervals expose more of a burst, while detailed request tracing or application logs may be needed to explain what caused it.

Read host I/O counters without confusing them with NAND writes

The Linux kernel documents cumulative I/O fields in /proc/diskstats and /sys/block/<device>/stat. For a whole disk, the read/write sector counters are in 512-byte units, even when the device's logical block size differs. Calculate bytes transferred during an interval as change in sector count × 512. Record both counter snapshots and timestamps. If the device restarted, was reattached or a counter wrapped, do not treat the resulting difference as a normal interval. Disk and partition counters also have different attribution and merge behavior; compare like with like.

On supported Windows Server configurations, Microsoft documents PhysicalDisk read/write byte rates, operation rates and average latency counters. Confirm which counters the actual Windows edition and device expose. Their reported rates average activity across the observation interval, so keep an interval short enough for the decision being made.

For an illustrative calculation, suppose a whole-disk write-sector counter increases by 168,750,000 over exactly 24 hours. That is 168,750,000 × 512 = 86,400,000,000 host bytes, or 86.4 decimal GB of host writes per day. It is not a Kalstor measurement or a count of physical NAND writes. Filesystem metadata that reaches the block layer may be included; controller garbage collection and other NAND-internal writes are not exposed by these host counters.

Report the read/write mix two ways if both are available: share of bytes and share of completed operations. A few large writes and many small reads can be write-heavy by bytes but read-heavy by operation count. Do not call either percentage simply “the read/write ratio” without its unit.

Mark what the counters cannot tell you

Aggregate totals do not give a distribution of request sizes, the addresses needed to judge sequential versus random access, the full distribution of outstanding requests, or p95/p99 completion latency. A documented average-latency counter is still only an average. For those missing fields, obtain an approved block trace, suitable application instrumentation or a vendor-specific diagnostic that actually exposes them. Also ask the application owner for its timeout or missed-record limit: a fast disk average does not define what the device can tolerate.

If tracing is impractical, keep the field marked unknown. Do not infer a precise 4 KiB versus 128 KiB mix from an average transfer size; merges and concurrent applications can hide the underlying requests.

Give procurement a one-page workload record

Complete one record per host configuration or workload class. For every measured figure, retain its source, time window and whether it is measured, estimated or unknown.

Do not fill this table with attractive sample numbers that could be mistaken for your system's data. A supplier can propose alternatives against clearly stated unknowns, but those alternatives remain conditional until the application is measured or tested.

Reproduce the profile on a test device

After observation, construct an acceptance workload from the recorded phases. fio can generate selected block sizes, read/write mixes, rates and I/O depths, and its structured output can show latency distributions. It is a workload generator, not a passive recorder of the production application. A synthetic run is useful only to the extent that its settings represent the real device, including relevant fill state, test duration and competing work.

Run write tests on dedicated samples with backed-up data; a misdirected job can destroy data. Compare the same configuration and measurement window across candidates. Keep any approximation visible, especially when request size or application timing is still unknown. The supplier and the system owner can then agree what the sample test proves and which gaps need an application-level trial.

Send the completed workload record with host interface, required life and operating conditions through the quote request. Kalstor can use those inputs to discuss a candidate storage configuration; media endurance, compatibility and performance still need confirmation for the exact part and qualification conditions.