A ZimaOS Files copy reporting roughly 600–650 MB/s does not prove the NVMe device itself is capped at SATA speed. The source community guide correctly separates raw storage throughput from file-copy workflow throughput. A browser-based file manager can add metadata, progress tracking, safety logic, userspace copies, filesystem overhead, and per-file operations that a direct benchmark does not measure.
The most useful approach is comparative: test the same storage with a large sequential direct-I/O workload, then copy the same large file through CLI and Files. If raw/direct tests are multiple GB/s while the GUI copy remains near 600 MB/s, the bottleneck is probably above the NVMe device.
One File-Copy Number Is Not an NVMe Benchmark
Internal copy speed depends on:
- source and destination being the same or different devices;
- filesystem type;
- copy-on-write behavior;
- file size and file count;
- CPU overhead;
- page cache;
- the copy implementation.
A 600 MB/s result can be excellent for one workflow and poor for another.
Start with a Large Sequential Test File
Large files reduce metadata noise and make sustained throughput easier to interpret. The source used a 10 GB file so the workload would run long enough to observe.
Before creating a large test file, verify that the target storage has plenty of free space. A benchmark that fills the system or data disk can create a different failure.
The Source Used dd with Direct Writes
The community guide proposed:
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct reduces page-cache effects on the write path. This is useful for a rough sequential write check.
Do not assume every build/device/filesystem accepts the same block size or direct-I/O behavior identically.
Be More Careful Interpreting the Source dd Read Test
The source then read the file to /dev/null. Without a direct-I/O read option or cache control, a recent file can be partially served from page cache and exaggerate apparent read speed.
For a reliable storage comparison, prefer a tool/configuration that explicitly uses direct I/O for both directions or ensure caching effects are understood.
fio Is the Better Controlled Storage Benchmark
The source's sustained write example used:
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reportingThis is still community guidance, but it has a clearer benchmark shape: explicit test size, sequential writes, queue depth, direct I/O, runtime, and grouped results.
Never point a destructive fio job at a raw device containing real data. Use a disposable test file on a filesystem unless you fully understand the consequences.
Compare GUI and CLI with the Same Dataset
The source's strongest methodological advice is to use the same large file for both:
- a CLI copy;
- a ZimaOS Files copy.
If the dataset, source, destination, and filesystem are identical, the difference more directly reflects the copy pipeline.
Small Files Can Be Dramatically Slower
Thousands of photos, project files, thumbnails, or AppData entries require repeated open/create/metadata/checksum operations. The aggregate transfer rate can fall far below a single large movie or ISO even on very fast NVMe.
Btrfs copy-on-write and metadata behavior can add further overhead depending on the exact operation.
Watch CPU and I/O While the Slow Copy Is Running
The source recommends observing disk utilization and CPU at the same time. The goal is to identify whether:
- the disk is saturated;
- one CPU core is the bottleneck;
- another process is competing for I/O;
- the copy pipeline is waiting rather than driving the storage.
This is more informative than quoting only the Files progress-bar number.
NVMe Speed Also Depends on PCIe Lanes and the Device
Even a healthy NVMe may run below its marketing number if:
- the slot is PCIe x1/x2 rather than x4;
- the platform is PCIe Gen 3 rather than Gen 4;
- the SSD is thermally throttling;
- the controller is sharing lanes;
- SLC cache is exhausted during sustained writes.
A real benchmark should be compared with the hardware topology, not with a generic “NVMe = 7 GB/s” expectation.
Current IceWhale Transfer Guides Also Separate UI and Faster Transfer Paths
IceWhale's ZimaCube Thunderbolt guide has historically shown the ZimaOS UI transfer path running slower than a direct Samba/Thunderbolt path, reinforcing the general point that the file UI is not identical to raw/network storage throughput.
Use the current ZimaOS transfer troubleshooting checklist for supported network-side checks.
Delete Test Files When You Finish
Large dd/fio files can consume tens of gigabytes quickly. Remove the known test files after recording the results and verify free space afterward.
NVMe Benchmark FAQ
Does 600 MB/s in ZimaOS Files prove the NVMe is capped at SATA speed?
No. It measures that copy workflow, not raw NVMe capability.
Why can a dd read appear unrealistically fast?
A recently written file can be served partly from page cache unless the read test explicitly avoids caching.
What is the best comparison for the GUI copy pipeline?
Use the same source/destination and same large dataset in both CLI and Files, then compare while monitoring CPU and storage I/O.
