НеизвестныйГ,

IOPS * TransferSizeInBytes = BytesPerSec

разумеется, зависит. Т.к. у разных файловых систем, причем с разными настройками, разная производительность. Имея в виду одно и то же железо, выше всего iops на raw-диске.

Под Windows все проще, т.к. есть либо FAT32, либо NTFS, причем использовать fat32 имеет смысл разве что на флэшках. Как ни странно, на одной и той же флэшке CrystalDiskMark на ntfs показывает гораздо лучшие результаты, чем на fat32.

На Линуксах все гораздо страшнее. Там туча разных файловых систем, и кроме есть еще разные системные шедулеры ввода-вывода (cfq, deadline, и какие-то еще). И например, у файловой системы EXT4 есть разные опции, например одна из них barrier (0 или 1), которая может ухудшить или улучшить скорость ввода-вывода в зависимости от других настроек этой файловой системы, и в зависимости от того, как приложение работает с файлом (random, sequential, и т.д.).

Поэтому для дисков показатель IOPS считается примерным. А конкретный IOPS - при обращении из приложения А к файлу на ОС Б с файловой системой В и настройками Г.

Тестовый софт (например IOMeter) при измерении IOPS обязан уметь указывать хотя бы часть специфики - file server, web server, database, размер блока, n параллельных обращений, и т.д.

JVFникак не зависит от ФС.
гм, похоже что да, и я имел в виду кучу дополнительных условий
"IOPS numbers by themselves are meaningless and should be treated as such. Without additional metrics such as latency, read vs write % and I/O size (to name a few), an IOPS number is useless."

Значения IOPS сами по себе бессмыслены и именно так должны пониматься. Без дополнительных метрик, таких как латентность, соотношение чтения и записи, и размера ввода-вывода, значения IOPS бесполезны.

Собственно, я имел в виду не "заявленные IOPS", а "измеряемые в конкретных условиях IOPS"
Вот тут вполне хорошее описание
http://blog.aboutnetapp.ru/archives/1204

JVFМожет скопировать 99% за одну секунду и потом висеть несколько минут до полного завершения.
это микрософт еще в Vista относительно XP поменял. Т.е. так работает индикатор. Потому что, например, если файл копируется с диска на флэшку, то
- либо файл не кэширован, и копируется и правда с диска на флэшку
- либо файл кэширован, и копируется из памяти (кэша) на флэшку.
в первом случае индикатор будет ползти медленно, во втором - быстро.
Дальше идет запись из кэша на флэшку - в XP индикатор копирования этого вообще не показывал, в результате чего пользователи выдергивали флэшку ДО записи кэша на нее, отсюда соответствующие проблемы (недописанные файлы на флэшке).
В Висте поменяли - индикатор теперь ждет завершения записи кэша в файлы на флэшке. Поэтому и "висит несколько минут до полного завершения". Зависит от размера файлов, разумеется.

p.s. я напомню, что в винде копирование файлов происходит так - сначала создается целевой файл требуемого размера, пустой (аллокируются секторы в файловой системе), а затем целевой файл последовательно заполняется содержимым исходного файла.

НеизвестныйГ,

зависит от диска, контроллера и т.д. Вот тест, который позволяет мерять на одном и том же файле разные размеры блока.
https://www.attotech.com/disk-benchmark/

запустите и посмотрите. Вот мой результат одного из дисков (старенький ST31000528AS).

JVFиндикатор копирования (Win, FAR) ведет вполне себе адекватно
тут я могу только теоретизировать - возможно, на этих файловых системах в ОС не используется кэширование записи (вернее, используется write-through или write-around вместо write-back).