Sorry for that (maybe) silly question, but is f3probe suitable for checking an external HDD's real size, or is this feature limited to flash block devices like SSDs, SDcards and USB Sticks?
I checked my new external HDD (WD-RD37SY5G SATA6 disk being connected to USB3.2 Gen1x1 via a JMicron JMS578) and got the following result:
````
=> Usable size: 7.28 TB (1953506646 blocks)
# I/O average speeds
=> Sequential write: 372.63 KB/s (524294 blocks / 1:33:48)
=> Random write: 444.08 KB/s (2257 blocks / 20.32s)
=> Random read: 659.10 KB/s (3238 blocks / 19.65s)
Good news: The device `/dev/sda' is the real thing
Device geometry:
*Usable* size: 7.28 TB (1953506646 blocks)
Announced size: 7.28 TB (1953506646 blocks)
Module: 8.00 TB (2^43 Bytes)
Approximate cache size: 0.00 Bytes (0 blocks)
Physical block size: 4.00 KB (2^12 Bytes)
I/O average speeds:
Sequential write: 372.63 KB/s (524294 blocks / 1:33:48)
Random write: 444.08 KB/s (2257 blocks / 20.32s)
Random read: 659.10 KB/s (3238 blocks / 19.65s)
Probe time: 1:34:28
Operation: total time / blocks = avg time
Read: 19.63s / 3238 = 6.0ms
Write: 1:34:05 / 526551 = 10.7ms
````
I'm wondering about no cache being detected (since I thought that also HDD controller usually have some cache as well), and the speed should significantly be higher (nominal up to max. 75MB during write access and 85MB during read access by the disk's datasheet), and I expected the sequential write being faster than the random write.
So is the result trustworthy in that case, or is a run with f3write + f3read recommended?
I'm not aware that the same fraud that occurs in the flash market also occurs in the HDD market. The reason for this is the much higher effort required to fake an HDD. Therefore, the conclusion "Good news: The device `/dev/sda' is the real thing" is expected for HDDs in general.
If you want to check if the whole drive is fine, you should test it with `f3write`/`f3read` or `f3brew`.
The cache estimate in `f3probe` is the one a fake controller uses to hide the fraud. If a cache is only used to speed up access, it's not accounted for.
_I used AI below to answer your observations on speed:_
**Why are the speeds so low (~370–660 KB/s) instead of 75–85 MB/s?**
The speeds reported by f3probe measure single-block synchronous I/O latency, not streaming sequential throughput:
Unbuffered Synchronous Access: `f3probe` issues direct, synchronous I/O operations on individual physical blocks ($4.00\text{ KB}$ each) to bypass operating system caching and observe hardware-level responses.
Mechanical Latency (Seek + Rotational Delay): Every synchronous read/write on a mechanical drive requires the drive head to seek to a track and wait for the platter to rotate into position.
Latency Breakdown:
Your probe summary explicitly reports the average time per operation:
Read latency: $6.0\text{ ms}$ per $4\text{ KB}$ block $\rightarrow \frac{4\text{ KB}}{0.0060\text{ s}} \approx 666.7\text{ KB/s}$
Write latency: $10.7\text{ ms}$ per $4\text{ KB}$ block $\rightarrow \frac{4\text{ KB}}{0.0107\text{ s}} \approx 373.8\text{ KB/s}$
A latency of $6\text{–}11\text{ ms}$ per operation ($\approx 90\text{–}160\text{ IOPS}$) is typical performance for a 5400/7200 RPM mechanical drive doing synchronous, single-block transfers.
Tools like `f3write` / `f3read` achieve the full rated $75\text{–}85+\text{ MB/s}$ throughput because they write large $1\text{ MB}$ streaming buffers asynchronously, allowing the drive controller to stream continuous sectors along entire tracks without waiting for per-block round-trip acknowledgments.
**Why is sequential write slower than random write in this output?**
Sample Size Disparity:
Sequential write test: $524,294\text{ blocks}$ over $1\text{ hour } 33\text{ minutes}$
Random write test: only $2,257\text{ blocks}$ over $20.32\text{ seconds}$
Over a brief $20\text{-second}$ window, short-term controller buffering or localized head movement can result in a minor variance ($\sim 444\text{ KB/s}$ vs $\sim 373\text{ KB/s}$), but both translate to the same order of magnitude ($\sim 10\text{ ms}$ per synchronous I/O).