Наверное, пора создавать блог и писать туда мысли по поводу сабжа и вообще копирования файлов.

Мысль первая:
Для того, чтобы быстро копировать, надо сделать три вещи:
1. Быстро читать
2. Быстро писать
3. Не давать медленной операции простаивать.

Первые два пункта решаются сравнительно просто, надо установить правильные флаги в функции CreateFile.

На третьем начинаются танцы. Если чтение и запись ведутся последовательно, ничего не сделаешь. Если параллельно - надо сделать упреждающее чтение. Но оно не поможет, если скорость чтения ощутимо меньше скорости записи. И получится, что ты напрасно выделил память под буфер А сравнить эти скорости можно только начав процесс копирования.

Dima TFlying-homeА кто-нибудь видел своими глазами скорость копирования по сети 100 мегабайт в секунду?

Точно! Надо будет еще и с Фаром посоревноваться.
А можно поинтересоваться, в каком окружении эта скорость была установлена? Какие винты и контроллеры на сервере и на клиенте?

Dima T
"Без сохранения на диск" - это как? Чистая скорость чтения?

А какой версией Фара пользуются благородные доны?

Dima TFlying-homeА какой версией Фара пользуются благородные доны?
Древняя, 2003 год: The FAR manager, version 1.70 beta 5 (build 1634)

Есть посвежее: Far Manager, version 3.0 (build 4949) x64. В ней 113.2 Мб/сек копирование в nul
А у него есть какие-то настройки копирования? Или алгоритм полностью универсальный?
В ТоталКоммандере есть:

вадяесть ещё прога teracopy http://codesector.com/teracopy , хорошо и быстро копирует, да ещё и может проверить скопированное.
Посмотрим.

Ситуация:
Копируем файлы с жесткого диска на SSD.
Скорость записи SSD заметно выше скорости чтения HDD, операции чтения на простаивают.
Все файлы небольшие, от 200 КБ до 19 МБ, 600 штук
Чтение безбуферное.

В первом случае читаются блоками по 2 МБ, в блок больше одного файла не читается.
Количество чтений - 1694

Во втором случае читаются блоками по 32 МБ, в блок может быть прочитано несколько файлов.
Количество чтений - 683

В обоих случаях остановок (пауз между операциями чтения) нет. Почему второй метод проигрывает 2% по скорости?

Если объем файлов увеличить в два раза, то и разница во времени копирования увеличивается в два раза.

Если скопировать эти файлы на тот же диск так, чтобы их фрагментация уменьшилась, то в обоих случаях скорость возрастает, но первый метод выигрывает те же 2%.

вадяесть ещё прога teracopy http://codesector.com/teracopy , хорошо и быстро копирует, да ещё и может проверить скопированное.
Школьная поделка.
Сходу проиграла мне 7%. 13 файлов, общий объем 8.5 ГБ. Мое время - 155 сек, ее - 167 (по ее данным).

maytonТы в эксперимент внёс ещё несколько неизвестных.

Когда копируешь 1 большой файл то можно достичь
Пропускной скорости диска.

Когда копируешь россыпь мелких то читающий
И пишущий диски начинают роутинг дискового каталога. А это движение по древовидными
Структурам. В игру включаются seek вызовы
И это сбивает основной алгоритм.

Размер блока в данном случае не имеет значения.
В первом случае я читаю 4-метровый файл за два последовательных прохода, которые, скорее всего, винчестер объединяет.
Во втором случае я читаю 4-метровый файл за один проход.

Dima TFlying-homeВ обоих случаях остановок (пауз между операциями чтения) нет. Почему второй метод проигрывает 2% по скорости?
ИМХО большим блоком ты мешаешь каким-то фоновым оптимизациям внутри ОС. Например упреждающее чтение: прочитав маленький блок, пока ты пишешь - ОС готовит тебе следующий блок, а при большом блоке ты тупо ждешь пока ОС тебе его прочитает.
При записи тоже есть нечто подобное.

1. Уменьши блок до 32-64 Кб.
2. Замерь скорость встроенных средств: CopyFile() CopyFileEx()
Это все справедливо для буферизированных операций. У меня чтение безбуферное, ось мне ничего не готовит.
Виндовые функции копирования CopyFile() и CopyFileEx() уже давно курят в сторонке.

Dima TПочитай про IoCompletionPort . У Рихтера неплохо было написано про него в "Windows via C/C++".
Уже было предложено и было мной прочитано.

Хотел бы в двух словах описать (как я это понимаю), как происходят безбуферные дисковые операции, чтобы исключить в дальнейшем предложения уменьшить размер буфера до 64К.

Что у Рихтера на эту тему

Виндовс, когда видит, что файл создан (или открыт) с флагом FILE_FLAG_NO_BUFFERING, делает две вещи: отменяет собственную буферизацию и говорит винчестеру, что хочет, чтобы он читал данные посекторно.
Так вот, если винчестер это понимает и может, если файл (или свободное пространство, если речь идет о записи) несильно фрагментированы, ты мы можем получить прирост скорости операции до 50%. Пример такого прироста мы видим в работе ФАРа (несколько постов выше). Для таких операций (при достаточно больших файлах) размер блока должен быть побольше. Из моих наблюдений скорость операций перестает расти после 16, 32 и 64 МБ. Интересно, что этот механизм работает и по сети.

Я не занимаюсь копированием файлов размером меньше 128 КБ, выделяю их копирование в отдельную задачу и использую CopyFile(). Получается быстрее, чем если копировать их вместе с большими файлами. Это потому что создание файла в файловой системе занимает больше времени, чем запись в него. Так же при создании файла головки винчестера делают лишние телодвижения для работы с MFT.

Но с файлами размером 2 МБ приходится возиться.

Почему я вообще этим занялся: из всех копировалок, которые я видел, ни одна не копировала бесшовно. И ни одна не пыталась использовать побольше памяти для упреждающего чтения. Я решил, что смогу на этих двух пунктах выиграть и уже выигрываю.
Бесшовно - значит без паузы межу файлами. К тому времени, когда пишущий поток закрывает очередной записанный файл, читающий поток уже должен прочитать ему первый блок следующего файла.

Вот иллюстрация к тому, что я говорил выше.
Это копирование кучи mp3-шек в сеть.

кол-во файлов кол-во блоков размер блока общий размер (байт) миллисекунды КБ/С МБ/С552 27 16 777 216 4 690 054 068 0 51 870 88 300.19 86.23552 15 33 554 432 4 690 054 068 0 48 298 94 830.65 92.61552 7 67 108 864 4 690 054 068 0 47 767 95 884.84 93.64TeraCopy4 690 054 068 77 000 59 482.22 58.09
Самый большой файл - 40 МБ, средний размер - 8 МБ.
Как видим, для безбуферных операций главная задача - уменьшить количество чтений/записи. А дальше уже вся надежда на винчестер и фрагментированность файлов / свободного места.