Улучшения в копировании в Vista

В прошлой части мы
начали разговор об улучшениях, которые приобрел механизм копирования в Windows.Vista.
Продолжим наше описание.

Ограничение, связанное с относительно маленькими и перемежающимися файловыми
операциями, заключается в  SMB драйвере файловой
системы, протоколе, отвечающем за сетевое разделение файлов. Он не способен
эффективно организовывать передачу данных по широким канал, по
WLAN сетям с высокими задержками. Каждый раз когда
локальная система ждет от удаленной получения данных, передача останавливается и
задержки происходят сразу на двух системах, ожидающих друг от друга ответа о
получении и очередной порции данных.

После изучения нескольких альтернатив команда разработчиков решила
остановиться на механизме, оперирующем большими асинхронными некэшированными
запросами на чтение/запись и таким образом решить все проблемы. С помощью
некэшированного механизма данные копируемого файла не потребляют память на
локальной системе, отсюда решение с перерасходом памяти. Асинхронность в чтении
и записи больших файлов позволит организовать канал передачи данных в сетях с
большими задержками, уменьшить занятость центрального процессора так как
Cache Manager-у уже
не надо будет перераспределять память. Неэффективность оригинального
Windows Vista
Cache Manager-а в обработке больших запросов так же склонила разработчиков
использовать некэшируемые I/O. Они не могли сделать
блоки данных произвольно большими, так как движок копирования должен читать
данные перед их записью, и выполнять чтение и запись желательно одновременно,
особенно в случае в деле копирования на разные диски или системы. Большие блоки
так же усложняют задачу оценки точного времени операции копирования для
пользователя, в такой ситуации меньше контрольных точек для определения
прогресса и обновления этого показателя. Но команда отметила значительный спад в
производительности некэшируемых запросов чтения/записи — в процессе копирования
многих маленьких файлов дисковой головке приходиться непрерывно перемещаться по
диску, сначала к источнику, потому к целевому файлу, потому обратно к источнику
и так далее.

После проведенного анализа, тестов и настройки,
программисты решили применить алгоритм, который использует кэшируемое
копирование для файлов меньше 256 Кб. Для файлов больше 256 Кб алгоритм
полагается на внутреннюю матрицу для определения количества и размера
некэшируемых операций чтения/записи которые придется выполнить за раз.
Количество это варьируется от 2 для файлов меньше 2 Мб до 8 для файлов больше 8
Мб. Размер блока чтения/записи равен размеру файла для файла меньше 1 Мб, 1 Мб
для файла до 2 Мб и 2 Мб для файла большего размера.

При копировании 16 Мб файла, например, движок
осуществляет восемь 2 Мб асинхронных некэшируемых чтений исходного файла,
ожидает завершения операции, выполняет восемь 2 Мб  асинхронных
некэшируемых операций записи целевого файла, снова ожидает окончания записи и
повторяет цикл. Вы можете увидеть такой механизм в трассировке
Process Monitor
копирования 16 Мб файла с локальной системы на удаленную:

В то время как механизм улучшен по сравнению с предыдущим по многим позициям,
есть у него и недостатки. Один из них эпизодически случается при сетевом
копировании, из-за не упорядоченных операций записи, одна из которых видна видна
в трассировке на принимающем копию компьютере:

Обратите внимание как смещение операции записи скачет с 327,680 до 458,752,
пропуская блок со смещением 393,216. Такой пропуск вызывает лишнее перемещение
головки диска и заставляет NTFS выполнить ненужную
операцию записи, записывая в пропущенный блок нули, так что в файле со смещением
393,216 будет две операции чтения. Ниже вы можете видеть как
NTFS вызывает
функцию Cache Manager-а CcZeroData для записи нулей в пропущенный блок:

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

(Продолжение следует)

Источник:
http://blogs.technet.com/markrussinovich/

Теги:

Оставить мнение

Check Also

Брутфорс в английской глубинке. Как криптостойкие шифры вскрывали до компьютеров

Ты наверняка слышал про тест Тьюринга и, возможно, машину Тьюринга. Однако помимо абстракт…