Flying-homeДля чтения с компакт или DVD диска файлы надо читать в том порядке, в котором они записаны на диск. Как это сделать? Как получить полный список файлов на диске, отсортированный в нужном порядке? И сколько времени займет получение этого списка? А если файлов много, а пользователь копирует только часть из них?
Какой у нас есть Api для DVD? Это тот-же самый файловый итератор findfirst/findnext для unix, FindFirstFile/FindNextFile для Windows.
И я не очень понимаю о какой сортировке идет речь. Предполагаю что в том порядке как выдает итератор так и надо
обрабатывать. Optimal way.

Альтернативный API - это копировать образ диска. Но это КМК другая задача.

Flying-homeЕще два наблюдения:

Собирать статистику скорости копирования в зависимости от параметров надо аккуратно и осмотрительно: например, копировать всегда в одно и тоже место диска.
Вчера сливал все скачанные с торрентов киношки с нескольких дисков на один терабайтник. В начале скорость была 138 МБ/с, запись обгоняла чтение. В конце скорость снизилась до 85 МБ/с, чтение стало обгонять запись.
Терабайтник одноблиновый, так что все понятно.
Да. Лет 10 назад была такая утилитка. HDTune. И она графиками подтверждает этот факт.

Flying-homemaytonИ я не очень понимаю о какой сортировке идет речь
Ну как, на компакт-диске всего одна дорожка. Для оптимального чтения надо сделать так, чтобы каретка с лазером двигалась вдоль дорожки и делала минимум переходов туда-сюда. А FindFirst/FindNext в каком порядке нам список файлов даст?
Я понимаю откуда идёт твой вопрос.

Надо почитать устройство компакт-диска. Стандарт DVD/BlueRay. Я думаю - закопаешся на пару месяцев.
Вангую что не будет практической пользы от ответа который ты найдешь.

Из далеких двухтысячных. Я помню что копирование CD на 700 мб. занимало много времени
когда в диске было дохрена мелких файлов. Спасали утилиты типа DaemonTools e.t.c.
Они позволяли копировать образ диска.

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

Очень сомнительно что ты создашь системную утилиту копирования дисков. Это
поле уже испахано. А даже если и создашь то никто за нее не заплатит. Вообще..
кто платит за разработку системного софта?

Вот за прикладной - платят.

Flying-homeDima Tпропущено...

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

1. Уменьши блок до 32-64 Кб.
2. Замерь скорость встроенных средств: CopyFile() CopyFileEx()
Должен извиниться, ты кое в чем прав. В природе существуют диски, которым нравится, когда с них читают маленькими блоками. На моем "стенде" уменьшение блока вплоть до 256 КБ дает стабильный прирост скорости. Дальше уменьшать блок нет смысла, потому что начнут играть роль мои собственные накладные расходы.
Но только на одном винчестере. Не исключено, что 32-64 КБ - для него будет оптимальным размером.
Но ПОЧЕМУ???
То что ты называешь винчестером - это технологический стек. Который состоит из цепочки
последовательно соединенных устройств. И выбрать для них оптимальный режим работы - большое исскусство есть.
Я даже думаю что задача твоя немного бесконечна и нерешаема. Как раз из-за разнообразия техники.
Главный поинт - блочное копирование параллельно через разделяемую память для процесса чтения и записи
ты вроде-бы уже сделал. Молодец. Дальнейшее улучшене - это подбор или "угадывание" оптимального размера
блока. +Кластер файловой системы. Для Windows NTFS к примеру есть формула (или табличка) где размер диска примерно
линейно связан с размером выбираемого кластера (автоматически) при форматировании. Грубо говоря - мелкие
диски получат мелкий кластер. А 10Терабайтник получит побольше.

Самое сложное в твоих экспериментах - это зафикировать начальные условия. И отделить мух от котлет. Тоесть
понять какие технологические аспекты влияют (антивирус или параллельно работающий индексатор файлов от Windows)
на скорость а какие не влияют никак.

Похоже вот она

https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs-fat-and-exfat

Насчет 4Кб на Ntfs5 я-бы поспорил. Я точно помню что форматировал в 2000х диски (толстого на тот
момент) размера 1-2 Гб и получал уже 8К кластер... ну да ладно. Пока приму как рекомендацию.

Flying-homemaytonМолодец.
Дык. Кто бы сомневался.

maytonКластер файловой системы. Для Windows NTFS к примеру есть формула (или табличка) где размер диска примерно
линейно связан с размером выбираемого кластера (автоматически) при форматировании. Грубо говоря - мелкие
диски получат мелкий кластер. А 10Терабайтник получит побольше.

Тут такой интересный момент... Для чтения и записи размер кластера не имеет никакого значения. Кластер - это атом хранения, а не операции.
Если операции безбуферные, то имеет значение только физический размер сектора, нельзя выбирать размер блока меньше его, или некратным ему. Можно, например, смело писать блоками по 1 МБ на раздел, отформатированный с размером кластера 4 МБ.
Если операции используют файловый буфер виндовс, то тогда вообще можно забыть про кластеры и сектора, все за тебя сделает винда.
Да. Но когда ты делаешь copy/move/delete дерева каталогов в NTFS - работают механизмы аллокации дисковой
памяти для тела файла и для структуры каталога. И в этот момент размер кластера важен. Это единца аллокации.
И это влияет на performance.

Flying-homeПрогнал на другом винчестере серию тестов на чтение с маленькими файлами.
Все так, как я рассуждаю здесь 21835484 . Чем больше блок, тем выше скорость.
Я немного запутался. Ты уже перешел с флешек на жесткие диски?