7

Robocopy имеет параметр командной строки /J рекомендуемый для копирования больших файлов (он копирует с использованием небуферизованного ввода-вывода).

Какие (если есть) недостатки есть? По какой причине это не включено по умолчанию? (Это то, что заставило меня думать, что МОЖЕТ быть минусы.)

3 ответа3

5

Отличный вопрос

Небуферизованный ввод / вывод - это простая копия файла из исходного местоположения в конечное местоположение. Буферизованный ввод / вывод расширяет простую копию, чтобы оптимизировать для будущих чтений (и записи в) того же файла, копируя файл в кэш файловой системы, который является областью виртуальной памяти. Буферизованный ввод / вывод влечет за собой снижение производительности при первом обращении к файлу, поскольку он должен копировать файл в память; однако, поскольку доступ к памяти быстрее, чем к диску, последующий доступ к файлам должен быть быстрее. Операционная система заботится о синхронизации записи файлов обратно на диск, и чтения могут быть извлечены непосредственно из памяти.

В примечании об использовании упоминаются большие файлы с буферизованным вводом / выводом, потому что:

  1. Предварительная стоимость дорогая. Снижение производительности с буферизованным вводом / выводом значительно хуже для больших файлов.
  2. Вы получаете мало взамен. Большие блоки файлов в любом случае обычно не остаются в кеше очень долго, если только у вас нет тонны памяти относительно размера файла.
  3. Это не может избежать дискового ввода-вывода. Чтение и запись больших файловых блоков данных увеличивает вероятность необходимости дискового ввода-вывода.
  4. Вам, вероятно, не нужно буферизовать все равно. Большие файлы, как правило, реже используются на практике, чем файлы меньшего размера.

Таким образом, есть компромисс, но то, что вам подходит, зависит от вашего конкретного случая. Если вы заархивируете кучу файлов и передаете zip-файл резервной копии, небуферизованный путь - это путь. Копировать кучу файлов, которые были только что изменены? Буфер должен быть быстрее.

Наконец, обратите внимание, что размер файла не является единственным фактором при выборе между буферизованным и небуферизованным. Как и в случае с любым кешем, кеш файловой системы быстрее, но меньше, чем источник за ним. Это требует стратегии замены кэша, которая определяет, когда выселять предметы, чтобы освободить место для новых предметов. Он теряет свою выгоду, когда часто используемые предметы выселяются. Например, если вы синхронизируете домашние каталоги пользователей в течение дня в отдельном месте (т. Е. Когда пользователи активно используют файлы), буферизованный ввод-вывод выиграет от файлов, уже находящихся в кэше, но может временно загрязнить кэш устаревшими файлами. ; с другой стороны, небуферизованный отказ от любых преимуществ уже кэшированных файлов. Нет явного победителя в таком случае.

Примечание: это также относится к xcopy /J

Подробнее см. В блоге Microsoft Ask The Performance Team .

1

Я попробовал следующее:

При копировании с быстрого устройства (NAS через Gigabit-Ethernet) на другое быстрое устройство (USB3-диск)

  • без /J: данные считываются в буфер и записываются после этого, поэтому сеть или жесткий диск простаивают
  • с /J: данные читаются и записываются без ожидания, поэтому сеть и жесткий диск используются одновременно

Я бы предложил использовать эту опцию.

0

Если вы копируете через глобальную сеть, я рекомендую НЕ включать параметр /J для больших файлов, поскольку среднее время копирования значительно увеличится. Файлы, которые я скопировал, были от 500 МБ до 23 ГБ.

На линии 50 Мбит / с я набрал в среднем 43,5 Мбит / с (другой трафик и служебные данные), но никогда не опускался ниже 32 Мбит / с БЕЗ / J. С / J мой средний был около 25 Мбит / с ... глядя на perfmon, я мог видеть большие пики и впадины внизу.

Надеюсь, это поможет кому-то.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .