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

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

Копирование в предыдущих Windows

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

Движок копирования полагается на
Windows Cache
Manager
для осуществления асинхронного опережающего чтения, которое
позволяет читать исходный файл в фоновом режиме, пока
Explorer занят записью данных на другой диск или удаленную систему. Он
так же использует
опережающую запись Cache Manager для
своевременного сброса содержания файлов из памяти обратно на диск так что бы
память могла бы быть быстро освобождена в случае необходимости и потери данных
при системном сбое диска были бы минимальны. Посмотреть механизм за работой вы
можете в


Process Monitor
, в данном случае приведена трассировка копирования 256 Кб
файла в Windows XP из одной директории в другую
(с фильтром на чтение и запись данных):

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

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

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

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

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

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

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

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

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

Источник:

http://blogs.technet.com/markrussinovich/

Читай так же:

История пропавшего
автозапуска

История
зависшего гаджета


История пропавшей DLL


История неудавшегося сжатия


Windows Defender: история одного торможения

Сам себе
Руссинович

 

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии