Почему сравнение файлов по содержимому существенно медленнее для сетевых шар, чем для USB?
Имеется домашний NAS на базе Windows 10 Pro и процессора i3 на сокете 1150, с 8 ГБ ОЗУ. Расшарено 5 жестких дисков 2-3 ТБ с приличными скоростями - серии WD Black, Seagate Constellation. Подключение к основному компьютеру напрямую через 2.5 Гбит/с адаптеры (больше тогда DAS, чем NAS).
Копирование файлов и их чтение идет на полной скорости жестких дисков, тут претензий нет (до 170 МБ/с). Но вот когда делаю сравнение по содержимому через FreeFileSync или Total Commander, скорость сравнения не поднимается выше 60 МБ/с. Для внешних жестких дисков, подключенных по USB 3.0, скорость сравнения доходит до 100 МБ/с, и это 2.5-дюймовые модели.
И вопрос с жирной звездочкой - почему так и что делать? Известно (через ProcMon), что обе программы читают файлы мелкими блоками по 250 кБ примерно, с флагом "без кэша". Для USB это похоже по барабану, но вот сеть видимо дает задержку где-то. Может есть у кого подобный опыт, параметры для реестра, что-нибудь.. 10 ТБ данных сравнить та еще задача, а периодически делать приходится, файлы важные, раз в год бывает один битый да обнаружится (на NAS).
Задержки между запросами блоков.
По сети ведь маршрутизировать пакеты нужно, а это стоит времени.
USB тоже не прост, но там маршрутизация всего по 128 потенциальным узлам и нет подсетей, в отличие от сетевых протоколов.
Например, выкинуть с NAS винды и использовать для поставленной задачи не виндокомбайны, а rsync, который не гоняет по сети файлы, обходясь достаточными для сравнения чексуммами. Ну, и папки читает на месте, а не перечитывает постоянно - вдруг удаленная изменилась.
Adamos, мне винду с NAS не выкинуть. Это для дома, Linux там избыточен и потенциальный источник проблем, которые не хочется решать, дом не работа всё-таки. Взять хотя бы имена файлов - 140 знаков на кириллице и на Linux с винды такой файл не скопируется, ищи их потом и переименовывай. Плюс наличие винды дает мне возможность в случае чего прогнать викторию и другие привычные виндовые утилиты. И т.д. и т.п. Сравнение по содержимому делаю раз в полгода, хочется понять как ускорить.
alexalexes, а это можно как-то ускорить? Jumbo-фреймы вот к примеру я пробовал, разницы не увидел. Зато разница на несколько МБ/с была при смене гигабита на 2.5G.
> обе программы читают файлы мелкими блоками по 250 кБ примерно, с флагом "без кэша"
при таком подходе вы сильно зависите от многих параметров, включая конкретные тайминги между операциями чтения, размеры дорожек, алгоритмы кеширования и размер кеша в самом диске и даже расположение файла по дорожкам, алгоритмов упреждающего чтения на диске и в системе (в частности установки флага SEQUENTIAL_READ).
суть примерно в следующем - когда приходит очередная команда чтения, то, насколько быстро вы сможете считать данные даже при последовательном чтении будет зависеть от текущего угла поворота диска (а при непоследовательном еще и от позиции головки). Если вам повезло, вы попадаете на нужный угол и начинаете считывать данные практически сразу, если не повезло - то придется ждать полного проворота диска и даже при последовательном чтении скорость падает в разы (разные дорожки имеют разный размер в зависимости от удаления от центра и на дорожку может приходиться несколько мегабайт, вместо чтения которых вы ждете проворота). Вполне может быть что на более мелком диске и при локальном подключении вы попадаете удачно, а на большом диске при подключении по сети ждете когда он провернется. При этом задержка при подключении по сети всегда будет выше (потому что расстояния больше) и вполне может быть что диск успевает провернуться на следующий сектор и вам приходится ждать полный оборот, когда при локальном подключении не успевает и вы считываете неприрывно. Эту проблему должно смягчать упреждающее чтение, но видимо как-то с ним не повезло.
Контрольные суммы (я пользуюсь HashCheck Shell Extension) хотел оставить на крайний случай, т.к. хоть и с околонулевой вероятностью, но возможны коллизии, а сравнение "байт с байтом" гарантирует 100% надежность. И чуть больше лишних телодвижений нужно проделать, в отличии от скрипта на FreeFileSync.
хоть и с околонулевой вероятностью, но возможны коллизии
Вероятность того, что вы проведёте незабываемую ночь с несколькими победительницами крупных традиционных конкурсов красоты одновременно и бесплатно, очень многократно выше, чем вероятность коллизии для случайного изменения случайных (т.е. реальных) файлов.
Total Commander - это хитрая штука. Она например может копировать файлы в несколько сессий.
Иногда это дает буст к скорости копирования а иногда может оказать "медвежью услугу" для некоторых
источников которые плохо параллелятся.
Провертье настройки Total Commander.
Вообще comparison требует сравнения всего содержимого файлов поэтому по сложности он эквивалентен
копированию "со всех шар" к себе в память. И срезать здесь углы нигде невозможно.
Через FreeFileSync, как я писал, тоже самое. Там чтение в один поток на диск. Хочется понять, почему USB быстрее быстрой сети в два раза именно и только на сравнении файлов. Там даже не случайный доступ же.
Ivan Ustûžanin, но простое копирование идет одинаково быстро. А сравнение идет с разницей в два раза. А HDD - это бутылочное горлышко с лимитом 170 МБ/с (или 1300 МБит/с) и медленным случайным доступом. Что-то не сходится, совсем не сходится, сеть в два раза по пропускной способности перекрывает возможности диска)
mayton2019, rsync разбивает файлы на блоки, считает от них контрольные суммы - и гоняет по сети только их. Соответственно, работает со скоростью локального диска.
разбивает файлы на блоки, считает от них контрольные суммы - и гоняет по сети только их. Соответственно, работает со скоростью локального диска.
для этого на обоих хостах должны быть агенты, которые будут заниматься разбивкой, это не срезание углов, это другая процедура с более сложной организацией
Ziptar, поэтому я и написал - "демон rsync". Он берет на себя эту задачу на удаленном хосте.
Но при этом не требует каких-то хитростей, покупок и настроек - штатно запускается на любой Убунте.
Уж если на удаленном сервере создано какое-то хранилище, завести там этого демона - совершенно не проблема.
