Изменения в системе копирования в Vista SP1

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

С детальным списком изменений вы можете ознакомиться в официальном документе Notable Changes in Windows Vista Service Pack 1, который вы можете скачать здесь.

Одно из усовершенствований, отмеченных в данном документе - это увеличение производительности при копировании файлов во множестве сценариев, включая локальное копирование файлов, копирование с удаленной не-Vista системы и копирование с удаленной SP1-системы. Однако как они были достигнуты? Ответ сложен и лежит в изменении движка копирования файлов между Windows XP и Vista, и других изменениях в SP1. Каждый из нас копирует файлы и я думаю, что стоит прервать цикл статей "Дело о…", и углубится в эволюцию движка копирования файлов, чтобы показать, каким образом SP1 увеличивает производительность данного процесса.

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


Копирование файлов в предыдущих версиях Windows
В свете всех альтернатив и несовершенности информации, доступной движку Windows, он пытается обработать все сценарии одинаково хорошо. До Windows Vista использовался прямой подход, который состоял в открытии и итогового, и копируемого файлов в кэшированном режиме, и последовательного чтения 64 Кб (60 Кб при сетевом доступе из-за ограничений протокола SMB1.0 по чтению информации за раз) за раз, и записи данных в место назначения. В случае если доступ к файлу получен с кэшируемой системой ввода-вывода, как противоположность ввода-вывода с отображением в памяти, или ввода-вывода с флагом, запрещающим кэширование, прочитанные или записанные данные хранятся в памяти, по крайней мере, до тех пор, пока менеджер памяти не решит, что память должна быть перераспределена для других целей, включая кэширование данных других файлов.

Движок копирования полагается на Windows Cache Manager для выполнения асинхронного опережающего чтения, который по сути дела в фоновом режиме считывает файл, пока Explorer занят записью данных на другой диск или удаленную систему. Также движок копирования полагается на механизм обратной записи Cache Manager для своевременного удаления содержимого скопированного файла из памяти обратно на диск, так что память может быть в случае необходимости быстро переназначена, так что риск потери данных в случае отказа дисковой системы минимизирован. Вы можете увидеть алгоритм в работе в данной трассировке Process Monitor, в которой показано копирование файла размером 256 КБ в Windows XP из одной папки в другую, причем включены фильтры, чтобы сфокусироваться на записи и чтении данных.

Первые данные Explorer читает с такта 0, который в данный момент не представлен в памяти, что заставляет Cache Manager провести некэшируемую операцию ввода-вывода (которая представляет собой операцию ввода-вывода, когда данные записываются напрямую на диск без кэширования их в памяти), чтобы взять данные из такта 1, как это показано на трассировке такта 1.

В трассировке стека Explorer вызывает функцию чтения файла в строке 22 в функции BaseCopyStream и Cache Manager косвенно вызывает некэшируемое чтение, оказав воздействие на отображение файла в памяти.

Так как Explorer открывает файл с рекомендацией о последовательном доступе (чего не видно в трассировке), то поток упреждающего чтения Cache Manager, запущенный в рамках процесса System, начинает чтение файла от имени Explorer в строках 2 и 3. Вы можете увидеть в строке 2 стека функцию упреждающего чтения.

Вы могли заметить, что первоначально упреждающее чтение нарушает регламентные правила по отношению к первоначальному некэшируемому чтению, вызванному первой операцией чтения Explorer, что приводит к перепозиционированию головок диска и снижению производительности, но Explorer остановил начавшуюся некэшируемую операцию ввода-вывода, когда заметил, что данные уже прочитаны Cache Manager. В общем Cache Manager остается на 128 Кб впереди Explorer во время копирования файла.

В 4-ой строке трассировки Explorer запускает первый проход чтения данных, а потом вы можете наблюдать последовательность случайных чтений и записей данных. В конце трассировки потока по кэшированию при записи Cache Manager, запущенному также в рамках процесса System, он удаляет данные целевого файла из памяти на диск, используя некэшируемую запись.


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

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

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

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

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

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

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

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

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

Возможно, наибольшим недостатком алгоритма, и, наверное, причиной недовольства большинства пользователей Vista, является то, что для копирования большой группы файлов размером от 256 Кб и до десятков мегабайт ощущаемая производительность может быть намного хуже, чем в Windows XP. Это происходит потому, что предыдущий алгоритм использования кэшируемого ввода-вывода файла позволяет Explorer закончить запись целевого файла в память и убрать окно копирования задолго до того, как поток записи Cache Manager фактически закончит запись данных на диск, а с некэшируемым копированием, реализованным в Vista, Explorer вынужден ждать окончания каждой операции записи, до того, как запустить следующую, и, в результате, пока все данные не окажутся на диске, не отобразит окончание копирования файлов. Explorer в Vista также ждет еще 12 секунд, перед тем как рассчитать продолжительность копирования, а алгоритм подсчета чувствителен к флуктуациям скорости копирования, и эти две причины усиливают недовольство пользователя медленным копированием.


Улучшения в SP1
Во время разработки Vista SP1 команда решила повторно обратиться к движку копирования, чтобы найти способы улучшения производительности и реальной и воспринимаемой производительности операций копирования для тех случаев, для которых она ухудшилась в новой реализации алгоритма. Самым большим изменением, на которое они пошли - они снова начали использовать кэшируемый ввод-вывод для всех операций по копированию файлов, причем как для локальных, так и удаленных, за исключением одного небольшого исключения, которое я коротко опишу. При использовании кэширования воспринимаемое время копирования и сценарии публикации намного лучше. Однако, несколько значительных изменений были необходимы в обоих алгоритмах копирования и в самой платформе необходимо было обратиться к недостаткам кэшируемого ввода-вывода, которые я заметил.

Одно дело, когда движок копирования SP1 не использует кэширование для удаленных копий файлов и это препятствует проблеме двойного кэширования, что достигается поддержкой клиентского драйвера Windows удаленной файловой системы - Rdbss.sys. Это происходит, поскольку драйверу передается команда, сообщающая ему не кэшировать удаленный файл на локальной системе, так как он был прочитан или записан. Вы можете увидеть, как эту команду инициирует Explorer в следующей выборке Process Monitor.

Еще одним усовершенствованием для удаленных копий является конвейерный ввод-вывод, инициируемый драйвером SMB 2.0 - srv2.sys, который является новинкой в Windows Vista и Windows Server 2008. Вместо инициации ввода-вывода 60 Кб информации по сети, как было в реализации SMB 1.0, теперь SMB 2.0 инициирует конвейерный ввод-вывод 64 Кб, так что даже если теперь драйвер получит от приложения большой результат ввода-вывода, то он отправит множество вводов-выводов по 64 Кб одновременно, позволив данным попадать от или к системе с несколько меньшей латентностью.

Движок копирования также иниициирует четыре первоначальных ввода-вывода размером от 128 Кб до 1 Мб в зависимости от размера копируемого файла, что запускает поток опережающего чтения Cache Manager, инициирующий операцию ввод-вывода. Изменения в платформе, внесенные в SP1 в Cache Manager, заставляют его исполнять более крупные операции ввода-вывода и для опережающего чтения и для опережающей записи. Больший ввод-вывод - единственный возможный вариант из-за работы, проведенной над системой ввода-вывода в оригинальной Vista для поддержки ввода-вывода размером более, чем 64 Кб, что было лимитом в предыдущих версиях Windows. Больший ввод-вывод также улучшает производительность при локальном копировании, так как есть несколько обращений к диску и несколько головок, что позволяет потоку опережающего чтения Cache Manager лучше соответствовать тому уровню, на котором память заполняется скопированными данными. Это уменьшает, хотя не исключает нагрузку на память системы, что приводит к тому, что активное содержимое памяти во время копирования оттуда удаляется. И наконец, для удаленных копий использование большого ввода-вывода позволяет использовать драйверу SMB 2.0 конвейерную обработку. Cache Manager инициирует чтение ввода-вывода, которое в два раза больше ввода-вывода, инициированного приложением, вплоть до 2 Мб в Vista и 16 Мб в Server 2008 и запись ввода-вывода вплоть до 1 Мб в Vista и 32 Мб в Server 2008.

Данная выборка из трассировки копирования файла размером 16 Мб с одной системы с Vista SP1 на другую показывает ввод-вывод в 1 Мб, запущенный Explorer, и опережающее чтение Cache Manager в 2 Мб, который выдается флагами, запрещающими кэширование ввода-вывода.

К сожалению, изменения в SP1 хоть и обеспечивают более высокую производительность, чем предыдущие версии Windows, но в некоторых специфических случаях производительность может быть ниже, чем в оригинальной версии Vista. Первый - копирование на или с удаленной системы с Server 2003 в медленной сети. Первоначальный движок копирования в Vista обеспечил бы высокую скорость копирования, но из-за проблемы с внеочередным вводом-выводом, о которой я уже говорил ранее, это могло вызвать неправильное поведение Cache Manager в Server 2003, что могло привести к тому, что вся память сервера была бы заполнена копиями данных. Изменения, внесенные в движок копирования в SP1, помогают этого избежать, однако из-за того, что движок инициирует ввод-вывод в 32 Кб вместо 60 Кб, производительность, которой можно достичь в сетях с высокой латентностью может достичь лишь половины от той, которой обладала оригинальная версия Vista.

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

Следует отметить, что в SP1 Explorer рассчитывает время копирования гораздо более быстрее, чем в RTM-версии Vista, да и алгоритм расчета стал более точным.

Копирование файлов не настолько просто, как это может показаться на первый взгляд, но команда разработчиков отнеслась к данным обратной связи пользователей Vista очень серьезно и провела не одну сотню часов, пробуя разнообразные подходы и подстраивая финальную реализацию, чтобы вернуть производительность большинства сценариев копирования, по крайней мере, до уровня предыдущих версий Windows, и радикально улучшила некоторые основные сценарии. Изменения действительны как для копирования через Explorer, так и для инициированного другими приложениями, которые используют API CopyFileEx. Благодаря этому вы увидите серьезные изменения по сравнению с предыдущими версиями Windows при копировании файлов в сетях с высокой латентностью и скоростью, где имеет место большой ввод-вывод, SMB 2.0, конвейерная обработка ввода-вывода и автоматически настраивающееся окно на прием TCP/IP-пакетов, которые в прямом смысле слова могут за одну минуту скопировать файл, на копирование которого в Windows XP или Server 2003 ушло бы минут десять.


Источник: http://blogs.technet.com/markrussinovich
Перевод: Zloy Kak Pё$