Модуль 5 Вариант 1
Модель операционной системы
В большинстве многопользовательских ОС приложения отделены от собственно ОС: код ее ядра выполняется в привилегированном режиме CPU (называемом режимом ядра), который обеспечивает доступ к системным данным и оборудованию. Код приложений выполняется в непривилегированном режиме CPU (называемом пользовательским) с неполным набором интерфейсов, ограниченным доступом к системным данным и без прямого доступа к оборудованию. Когда программа пользовательского режима вызывает системный сервис, CPU перехватывает вызов и переключает вызывающий поток в режим ядра. По окончании работы системного сервиса ОС переключает контекст потока обратно в пользовательский режим и продолжает его выполнение.
Windows, как и большинство UNIX-систем, является монолитной ОС — в том смысле, что большая часть ее кода и драйверов использует одно и то же пространство защищенной памяти режима ядра. Это значит, что любой компонент ОС или драйвер устройства потенциально способен повредить данные, используемые другими компонентами ОС. Поддержка режимов функционирования современных CPU. Современные компьютеры обладают CPU, которые могут параллельно выполнять несколько потоков команд. В многозадачной системе CPU переключается между программами, предоставляя каждой от десятков до сотен миллисекунд. При этом в каждый конкретный момент времени CPU занят только одной программой, но за секунду он успевает поработать с несколькими программами, создавая у пользователей иллюзию параллельной работы со всеми программами. Следить за работой параллельно идущих процессов достаточно трудно, поэтому со временем разработчики ОС разработали концептуальную модель последовательных процессов, упрощающую эту работу. 2. Понятие процесса в Windows
Программа представляет собой статический набор команд, а процесс — это контейнер для набора ресурсов, используемых при выполнении экземпляра программы. На самом высоком уровне абстракции процесс в Windows включает следующее:
закрытое виртуальное адресное пространство — диапазон адресов виртуальной памяти, которым может пользоваться процесс;
исполняемую программу — исполняемый код и данные, проецируемые навиртуальное адресное пространство процесса;
список открытых описателей (handles) различных системных ресурсов — семафоров, коммуникационных портов, файлов и других объектов, доступных всем потокам в данном процессе;
контекст защиты (security context), называемый маркером доступа (асcess token) и идентифицирующий пользователя, группы безопасности и привилегии, сопоставленные с процессом;
уникальный идентификатор процесса (во внутрисистемной терминологии называемый идентификатором клиента);
минимум один поток.
Каждый процесс также указывает на свой родительский процесс (процесс-создатель).
Однако, если родитель существует, эта информация не обновляется. Поэтому есть вероятность, что некий процесс указывает на уже несуществующего родителя. Это не создает никакой проблемы, поскольку никто не полагается на наличие такой информации.
Понятие блока процесса и потока.
Каждый процесс в Windows представлен блоком процесса (EPROCESS), создаваемым исполнительной системой. Кроме многочисленных атрибутов, относящихся к процессу, в блоке EPROCESS содержатся указатели на некоторые структуры данных.
3. Понятие потока в Windows. Структура данных описывающая поток ETHREAD. Структура KTHREAD.
Поток — некая сущность внутри процесса, получающая время CPU для выполнения. Без потока программа процесса не может выполняться. Поток включает следующие наиболее важные элементы:
содержимое набора регистров CPU, отражающих состояние CPU;
два стека, один из которых используется потоком при выполнении в режиме ядра, а другой — в пользовательском режиме;
закрытую область памяти, называемую локальной памятью потока (thread-local storage, TLS) и используемую подсистемами, библиотеками исполняющих систем run-time libraries) и DLL;
уникальный идентификатор потока (во внутрисистемной терминологии также называемый идентификатором клиента: идентификаторы процессов и потоков генерируются из одного пространства имен и никогда не перекрываются);
Иногда потоки обладают своим контекстом защиты, который обычно используется многопоточными серверными приложениями, подменяющими контекст защиты обслуживаемых клиентов.
Переменные регистры, стеки и локальные области памяти называются контекстом потока. Поскольку эта информация различна на каждой аппаратной платформе, на которой может работать Windows, соответствующая структура данных специфична для конкретной платформы.
Структура данных описывающая поток ETHREAD. У каждого процесса есть один или более потоков, представляемых блоками потоков (ЕТНREAD) исполнительной системы. Блок EPROCESS и связанные с ним структуры данных, за исключением блока переменных окружения процесса (process environment block, РЕВ) — существуют в системном пространстве. РЕВ находится в адресном пространстве процесса, так как содержит данные, модифицируемые кодом пользовательского режима.
Структура KTHREAD
Блок процесса ядра(KPROCESS) - Общий заголовок объекта диспетчера, указатель на каталог страниц процесса, список блоков потоков ядра (KTHREAD), принадлежащих процессу, базовый приоритет по умолчанию выделяемый квант времени CPU, маска привязки к CPU, а также суммарное время работы потоков в режиме ядра и пользовательском режиме
4. Размер памяти, поддерживаемый ОС Windows для разных платформ. Задачи диспетчера памяти. Трансляция (проецирование). Рабочий набор. Подкачка.
Задачи Диспетчера памяти
Диспетчер памяти предоставляет набор системных сервисов для выделения и освобождения виртуальной памяти, разделения памяти между процессами, проецирования файлов в память, сброса виртуальных страниц на диск, получения информации о диапазоне виртуальных страниц, изменения атрибутов защиты виртуальных страниц и блокировки в памяти. В него входят три группы прикладных функций управления памятью:
для операций со страницами виртуальной памяти
проецирования файлов в память
управления кучами.
Рабочий набор
Подмножество виртуальных страниц, резидентных в физической памяти, называется рабочим набором (working set). Существует три вида рабочих наборов:
процесса — содержит страницы, на которые ссылаются его потоки;
системы — содержит резидентное подмножество подкачиваемого системного кода (например, Ntoskrnl.exe и драйверов), пула подкачиваемой памяти и системного кэша;
сеанса — в системах с включенной службой Terminal Services каждый сеанс получает свой рабочий набор.
Трансляция
Трансляция, или проецирование (mapping), виртуального адресного пространства процесса на физическую память. Это позволяет ссылаться на корректные адреса физической памяти, когда потоки, выполняемые в контексте процесса, читают и записывают в его виртуальном адресном пространстве. Физически резидентное подмножество виртуального адресного пространства процесса называется рабочим набором (working set).
Подкачка.
Самая простая стратегия, называемая свопингом (swapping) или обычной подкачкой, заключается в том, что каждый процесс полностью переносится в память, работает некоторое время и затем целиком возвращается на диск. в результате подкачки процессов с диска в памяти появляется множество неиспользованных фрагментов, их можно объединить в один большой участок, передвинув все процессы в сторону младших адресов настолько, насколько это возможно. Такая операция называется уплотнением или сжатием памяти. Обычно ее не выполняют, потому что на нее уходит много времени работы процессора.
5. Классы безопасности. Trusted Computer System Evaluation Criteria (TCSEC). Рейтинг безопасности TCSEC. Требования, которым удовлетворяет уровень безопасности C2. Common Criteria (CC).
Четкие стандарты безопасности программного обеспечения, в том числе ОС, помогают правительству, корпорациям и индивидуальным пользователям защищать хранящиеся в компьютерных системах данные, составляющие личную и коммерческую тайну. Текущий стандарт на рейтинги безопасности, применяемый в США и многих других странах, — Common Criteria (CC).
Trusted Computer System Evaluation Criteria
Стандарт TCSEC состоит из рейтингов «уровней доверия» («levels of trust» ratings), где более высокие уровни строятся на более низких, за счет последовательного ужесточения требований к безопасности и проверке. Ни одна ОС не соответствует уровню A1 (Verified Design). Хотя некоторым ОС присвоен один из уровней В, уровень С2 считается достаточным и является высшим для ОС общего назначения.
Common Criteria В январе 1996 года США, Великобритания, Германия, Франция, Канада и Нидерланды опубликовали совместно разработанную спецификацию оценки безопасности Common Criteria for Information Technology Security Evaluation (CCITSE). Эта спецификация, чаще называемая Common Criteria (CC), является международным стандартом оценки степени защищенности продуктов.
СС гибче уровней доверия TCSEC и по структуре ближе ITSEC, чем TCSEC. СС включает две концепции:
профиля защиты — требования к безопасности разбиваются нагруппы, которые легко определять и сравнивать;
объекта защиты — пред ставляет набор требований к защите, которые могут быть подготовлены с помощью профиля защиты.
6. Компоненты подсистемы ввода-вывода. Графическая интерпретация подсистемы ввода-вывода.
Для реализации этой функциональности подсистема ввода-вывода в Windows состоит из нескольких компонентов исполнительной системы и драйверов устройств).
Центральное место в этой подсистеме занимает диспетчер ввода-вывода; он подключает приложения и системные компоненты к виртуальным, логическим и физическим устройствам, а также определяет инфраструктуру, поддерживающую драйверы устройств.
Драйвер устройства, как правило, предоставляет интерфейс ввода-вывода для устройств конкретного типа. Такие драйверы принимают от диспетчера ввода- вывода команды, предназначенные управляемым ими устройствам, и уведомляют диспетчер ввода-вывода о выполнении этих команд. Драйверы часто используют этот диспетчер для пересылки команд ввода-вывода другим драйверам,
задействованным в реализации интерфейса того же устройства и участвующим в управлении им.
Диспетчер PnP работает в тесном взаимодействии с диспетчером ввода-вывода и драйвером шины (bus driver) - одной из разновидностей драйверов устройств. Он управляет выделением аппаратных ресурсов, а также распознает устройства и реагирует на их подключение или отключение.
Диспетчер электропитания, также в тесном взаимодействии с диспетчером ввода- вывода, управляет системой и драйверами устройств при их переходе в различные состояния энергопотребления.
Реестр служит в качестве базы данных, в которой хранится описание основных устройств, подключенных к системе, а также параметры инициализации драйверов и конфигурационные настройки.
Для установки драйверов используются INF-файлы; они связывают конкретноеаппаратное устройство с драйвером, который берет на себя ведущую роль в управлении этим устройством.
Уровень абстрагирования от оборудования (HAL) изолирует драйверы от специфических особенностей конкретных процессоров и контроллеров прерываний, поддерживая API, скрывающие межплатформенные различия. В сущности HAL является драйвером шины для тех устройств на материнской плате компьютера, которые не контролируются другими драйверами. 7. Драйверы дисков. Стек драйверов устройств внешней памяти в Windows.
При инициализации диспетчер ввода-вывода запускает драйверы жестких дисков. В архитектуре драйверов дисковой памяти только драйверы класса имеют стандартные интерфейсы драйверов устройств Windows. Минипорт-драйверы вместо интерфейса драйверов устройств используют интерфейс порт-драйверов, который просто реализует набор процедур, служащих интерфейсом между Windows и минипорт-драйверами. Такой подход упрощает разработку минипорт-драйверов, поскольку Microsoft предоставляет порт-драйверы, специфичные для ОС, а также обеспечивает переносимость минипорт-драйверов на уровне двоичного кода между Windows 98, Windows Millennium Edition и Windows.
Драйверы устройств, участвующие в управлении конкретным устройством внешней памяти (накопителем), обобщенно называются стеком драйверов внешней памяти (storage stack).
Первой частью процесса загрузки ОС Windows дирижирует Ntldr. Он находится на системном томе и запускается кодом, размещенным в загрузочном секторе этого тома. Ntldr считывает с системного тома файл Boot.ini и предлагает пользователю выбрать вариант загрузки. Ntldr транслирует имя выбранного пользователем элемента Boot.ini в имя загрузочного раздела и загружает в память системные файлы Windows (начиная с реестра, Ntoskrnl.exe и загрузочных драйверов). Во всех случаях Ntldr использует BIOS для чтения диска, содержащего системный том, но, иногда полагается на функции минипорт-драйвера диска для чтения с диска, где находится загрузочный том. 8. Архитектура драйвера файловой системы (ФС). Особенности драйверов ФС.
Драйвер файловой системы управляет форматом файловой системы. Хотя FSD выполняются в режиме ядра, у них есть целый ряд особенностей по сравнению со стандартными драйверами режима ядра. Возможно, самой важной особенностью является то, что они должны регистрироваться у диспетчера ввода-вывода и более интенсивно взаимодействовать с ним. Кроме того, для большей производительности FSD обычно полагаются на сервисы диспетчера кэша. Таким образом, FSD используют более широкий набор функций, экспортируемых Ntoskrnl, чем стандартные драйверы. Если для создания стандартных драйверов режима ядра требуется Windows DDK, то для создания драйверов файловых систем понадобится Windows Installable File System (IFS) Kit (подробнее o DDK см. главу 1; подробнее о IFS Kit см. www.microsoft.com/whdc/devtools/ifskiP). B Windows два типа драйверов файловых систем:
• локальные FSD, управляющие дисковыми томами, подключенными непосредственно к компьютеру;
• сетевые FSD, позволяющие обращаться к дисковым томам, подключенным к удаленным компьютерам.
Вариант 2.
Общая архитектура ОС Windows.
Windows включает следующие компоненты режима ядра:
Исполнительная система (executive) Windows, содержащая базовые сервисы ОС, которые обеспечивают управление памятью, процессами и потоками, защиту, ввод-вывод и взаимодействие между процессами.
Ядро (kernel) Windows, содержащее низкоуровневые функции ОС, которые поддерживают, например, планирование потоков, диспетчеризацию прерываний и исключений, а также синхронизацию при использовании нескольких CPU. Оно также предоставляет набор процедур и базовых объектов, применяемых исполнительной системой для реализации структур более высокого уровня.
Драйверы устройств (device drivers), в состав которых входят драйверы аппаратных устройств, транслирующие пользовательские вызовы функции ввода-вывода в запросы, специфичные для конкретного устройства, а также сетевые драйверы и драйверы файловых систем.
Уровень абстрагирования от оборудования (hardware abstraction layer, HAL), изолирующий ядро, драйверы и исполнительную систему Windows от специфики оборудования на данной аппаратной платформе (например, от различий между материнскими платами).
Подсистема поддержки окон и графики (windowing and graphics system), реализующая функции графического пользовательского интерфейса (GUI), более известные как Windows-функции модулей USER и GDI. Эти функции обеспечивают поддержку окон, элементов управления пользовательского интерфейса и отрисовку графики.
Основные этапы создания процесса в Windows
Создание Windows-процесса осуществляется вызовом одной из таких функций, как CreateProcess, CreateProcessAsUser, CreateProcessWtihTokenW или CreateProcessWithLogonW, и проходит в несколько этапов с участием трех компонентов ОС: Kernel32.dll (библиотеки клиентской части Windows), исполнительной системы и процесса подсистемы окружения Windows (Csrss).
Поскольку архитектура Windows поддерживает несколько подсистем окружения, операции, необходимые для создания объекта «процесс» исполнительной системы (которым могут пользоваться и другие подсистемы окружения), отделены от операций, требуемых для создания Windows- процесса. Поэтому часть действий Windows-функции CreateProcess специфична для семантики, привносимой подсистемой Windows.
Особенности планирования потоков для многопроцессорных систем. БД диспетчера ядра в многопроцессорных системах. Маска активных CPU.
База данных диспетчера ядра в многопроцессорной системе В такой БД хранится информация, поддерживаемая ядром и необходимая для планирования потоков. В многопроцессорных системах Windows 2000 и Windows ХР очереди готовых потоков и сводка готовых потоков имеют ту же структуру, что и в однопроцессорных системах. Кроме того, Windows поддерживает две битовые маски для отслеживания состояния процессоров в системе. Вот что представляют собой эти маски.
Маска активных процессоров (KeActiveProcessors), в которой устанавливаются биты для каждого используемого в системе CPU. (Их может быть меньше числа установленных CPUs, если лицензионные ограничения данной версии Windows не позволяют задействовать все физические CPUs.)
Сводка простоя (idle summary) (KildleSummary), в которой каждый установленный бит представляет простаивающий CPU. Если в single-CPU системе диспетчерская база данных блокируется повышением IRQT (в Windows 2000 и Windows XP до уровня «DPC/dispatch», а в Windows Server 2003 до уровней «DPC/dispatch» и «Synch»), то в multi-CPU системе требуется большее, потому что каждый CPU одновременно может повысить IRQL и попытаться манипулировать этой базой данных.
Базовый набор сервисов. Компоненты диспетчера памяти.
Сервисы – это программы, которые выполняют больший список действий, чем драйверы. Эти действия связаны с предоставлением общих функций всем программам.
Компоненты диспетчера памяти
Диспетчер памяти является частью исполнительной системы Windows, содержится в файле Ntoskrnl.exe и включает следующие компоненты наборов сервисов исполнительной системы для выделения, освобождения и управления виртуальной памятью:
Диспетчер рабочих наборов (working set manager) с приоритетом 16. Он реализует общие правила управления памятью, например усечение рабочего набора, старение и запись модифицированных страниц.
Поток загрузки и выгрузки стеков (process/stack swapper) с приоритетом 23. Выгружает (outswapping) и загружает (inswapping) стеки процесса и потока. При необходимости операций со страничным файлом этот поток пробуждается диспетчером рабочих наборов и кодом ядра, отвечающим за планирование.
Подсистема записи модифицированных страниц (modified page writer) с приоритетом 17. Записывает измененные страницы, зарегистрированные в списке модифицированных страниц, обратно в соответствующие страничные файлы. Этот поток пробуждается, когда возникает необходимость в уменьшении размера списка модифицированных страниц.
Подсистема записи спроецированных страниц (mapped page writer) с приоритетом 17. Записывает измененные страницы спроецированных файлов на диск. Пробуждается, когда нужно уменьшить размер списка модифицированных страниц или когда страницы модифицированных файлов находятся в этом списке более 5 минут.
Поток сегмента разыменования (dereference segment thread) с приоритетом 18. Отвечает за уменьшение размеров системного кэша и изменение размеров страничного файла.
Поток обнуления страниц (zero page thread) с приоритетом 0. Заполняет нулями страницы, зарегистрированные в списке свободных страниц.
Компоненты и БД защиты в ОС Windows
Ниже перечислены главные компоненты и базы данных, на основе которых реализуется защита в Windows.
Монитор состояния защиты (Security Reference Monitor, SRM).
Подсистема локальной аутентификации (local security anthentication subsystem, LSASS).
База данных политики LSASS. База данных, содержащая параметры политики безопасности локальной системы..
Диспетчер учетных записей безопасности (Security Accounts Manager, SAM).
База данных SAM. База данных, которая содержит информацию о локальных пользователях и группах вместе с их паролями и другими атрибутами.
Active Directory хранит информацию об объектах домена, в том числе о пользователях, группах и компьютерах. Сведения о паролях и привилегиях пользователей домена и их групп содержатся в Active Directory и реплицируются на компьютеры.
Пакеты аутентификации.
Процесс входа (Winlogon).
Служба сетевого входа (Netlogon). Windows-сервис, устанавливающий защищенный канал с контроллером домена, по которому посылаются запросы, связанные с защитой.
Kernel Security Device Driver (KSecDD). Библиотека функций режима ядра, реализующая интерфейсы LPC (local procedure call), которые используются другими компонентами защиты режима ядра.
Функциональность подсистемы ввода-вывода.
Согласно целям, поставленным при разработке, подсистема ввода-вывода в Windows должна обеспечивать приложениям абстракцию устройств — как аппаратных (физических), так и программных (виртуальных или логических) — и при этом предоставлять следующую функциональность:
стандартные средства безопасности и именования устройств для защиты разделяемых ресурсов;
высокопроизводительный асинхронный пакетный ввод-вывод для поддержки масштабируемых приложений;
сервисы для написания драйверов устройств на высокоуровневом языке и упрощения их переноса между разными аппаратными платформами;
поддержку многоуровневой модели и расширяемости для добавления драйверов, модифицирующих поведение других драйверов или устройств без внесения изменений в них;
динамическую загрузку и выгрузку драйверов устройств, чтобы драйверы можно было загружать по требованию и не расходовать системные ресурсы без необходимости;
поддержку Plug and Play, благодаря которой система находит и устанавливает драйверы для нового оборудования, а затем выделяет им нужные аппаратные ресурсы;
управление электропитанием, чтобы система и отдельные устройства могли переходить в состояния с низким энергопотреблением;
поддержку множества устанавливаемых файловых систем, в том числе FAT, CDFS (файловую систему CD-ROM), UDF (Universal Disk Format) и NTFS;
Базовые диски. Разбиение на разделы по схеме MBR. Разбиение на разделы по схеме GPT. Диспетчер томов на базовых дисках
Базовые и динамические диски
ОС должна иметь возможность управлять физическим пространством на жестком диске. Есть две структуры, которые помогают Windows распределять дисковое пространство: базовые и динамические диски.
Базовые диски разбивают на разделы, каждый из которых функционирует как физически отдельная единица хранения. Информация о расположении и размере каждого раздела хранится на диске в таблице разделов главной загрузочной записи (Master Boot Record, MBR). Базовый диск может содержать до четырех разделов: четыре основных либо три основных и один дополнительный.
Разбиение на разделы по схеме MBR
Одно из требований к формату разбиения на разделы в Windows диктуется стандартными реализациями BIOS в системах: первый сектор основного диска должен содержать главную загрузочную запись (Master Boot Record, MBR). При запуске компьютера на базе x86-npoцeccopa BIOS считывает MBR и интерпретирует ее часть как исполняемый код. Выполнив предварительное конфигурирование оборудования, BIOS передает управление исполняемому коду в MBR для инициации процесса загрузки операционной системы.
Отличие главного раздела от логических дисков становится очевидным при загрузке Windows. Один из главных разделов основного жесткого диска должен быть помечен системой как активный. Код Windows, записываемый в MBR, загружает в память код первого сектора активного раздела (системного тома) и передает ему управление. Первый сектор такого раздела называется загрузочным.
Разбиение на разделы по схеме GPT
EFI определяет схему разбиения на разделы — таблицу разделов GUID (GUID Partition Table, GPT), которая должна устранить некоторые недостатки схемы разбиения MBR. Например, адреса секторов, используемых структурами разделов GPT, вместо 32-разрядных стали 64-разрядными. 32-разрядные адреса обеспечивают доступ к 2 Тб памяти, но GPT разработана с прицелом на обозримое будущее. Среди прочих преимуществ GPT стоит отметить применение контрольных сумм CRC (cyclic redundancy checksums) для поддержания целостности таблицы разделов, а также резервное копирование таблицы разделов. GPT получила такое название из-за того, что кроме 36-байтового Unicode-имени она назначает каждому разделу свой GUID.
Диспетчер томов на базовых дисках
Драйвер FtDisk (\Windows\System32\Drivers\Ftdisk.sys) создает объекты «устройство» дисков для представления томов на базовых дисках и играет основную роль в управлении всеми томами на базовых дисках, включая простые тома. Для каждого тома FtDisk создает объект «устройство» вида \Device \Hard-diskVolumeX, гдеХ- число, которое идентифицирует том и начинается с 1.
Драйверы локальных ФС: описание, назначение, архитектура
Архитектура драйвера файловой системы
Драйвер файловой системы (file system driver, FSD) управляет форматом файловой системы. Хотя FSD выполняются в режиме ядра, у них есть целый ряд особенностей по сравнению со стандартными драйверами режима ядра. Возможно, самой важной особенностью является то, что они должны регистрироваться у диспетчера ввода- вывода и более интенсивно взаимодействовать с ним. Кроме того, для большей производительности FSD обычно полагаются на сервисы диспетчера кэша. Таким образом, FSD используют более широкий набор функций, экспортируемых Ntoskrnl, чем стандартные драйверы.
Если для создания стандартных драйверов режима ядра требуется Windows DDK, то для создания драйверов файловых систем понадобится Windows Installable File System (IFS) Kit.
B Windows два типа драйверов файловых систем:
локальные FSD, управляющие дисковыми томами, подключенными непосредственно к компьютеру;
сетевые FSD, позволяющие обращаться к дисковым томам, подключенным к удаленным компьютерам.
Локальный FSD должен зарегистрироваться у диспетчера ввода- вывода. После регистрации FSD диспетчер ввода-вывода может вызывать его для распознавания томов при первом обращении к ним системы или одного из приложений. Процесс распознавания включает анализ загрузочного сектора тома и, как правило, метаданных файловой системы для проверки ее целостности.
Все поддерживаемые Windows файловые системы резервируют первый сектор тома как загрузочный. Загрузочный сектор содержит достаточно информации, чтобы FSD мог идентифицировать свой формат файловой системы тома и найти любые метаданные, хранящиеся на этом томе. Распознав том, FSD создает объект «устройство», представляющий смонтированную файловую систему. Диспетчер ввода-вывода связывает объект «устройство» тома, созданный драйвером устройства внешней памяти (далее — объект тома), с объектом «устройство», созданным FSD (далее — объект FSD), через блок параметров тома (VPB). Это приводит к тому, что диспетчер ввода-вывода перенаправляет через VPB запросы ввода-вывода, адресованные объекту тома, на объект FSD.
Для большей производительности локальные FSD обычно используют диспетчер кэша, который кэширует данные файловой системы, в том числе ее метаданные. Они также интегрируются с диспетчером памяти, что позволяет корректно реализовать проецирование файлов. Например, всякий раз, когда приложение пытается обрезать файл, они должны запрашивать диспетчер памяти, чтобы убедиться, что за точкой отсечения файл не проецируется ни одним процессом. Windows не разрешает удалять данные файла, проецируемого приложением. Локальные FSD также поддерживают операции демонтирования файловой системы, позволяющие ОС отсоединять FSD от объекта тома. Демонтирование происходит каждый раз, когда приложение напрямую обращается к содержимому тома или когда происходит смена носителя, сопоставленного с томом. При первом обращении приложения к носителю после демонтирования диспетчер ввода-вывода повторно инициирует операцию монтирования тома для этого носителя.