Книга: Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003

6.5 Файловая система NTFS

6.5 Файловая система NTFS

Эта файловая система проектировалась специально для Windows NT. С момента первого появления NTFS в нее вносилось несколько модификаций, но основная архитектура оставалась неизменной. Файловых систем FAT и HPFS (High-Performance File System), поддерживаемых Microsoft в момент появления NTFS, было явно недостаточно для удовлетворения потребностей Windows NT.

Файловая система FAT не предоставляет необходимого уровня безопасности файлов и объектов.

Файловая система FAT не поддерживает возможностей по обработке вместительных жестких дисков, доступных в настоящий момент. (Вспомните, что изначально FAT проектировалась для использования на дисках объемом 1 Мбайт.)

Как FAT, так и HPFS не поддерживают транзакций, которые необходимы для обеспечения надежности данных и их восстановления после отказов в работе системы.

Файловая система NTFS предоставляет различные возможности, которые перечислены ниже и подробно описываются далее в главе.

Поддержка транзакций в NTFS обеспечивает регистрацию всех изменений метаданных файловой системы в специальном журнале, который поддерживает восстановление в случае неисправности.

Все данные, включая метаданные системы, хранятся в файлах.

NTFS и программные интерфейсы приложений Win32 поддерживают использование 64-разрядных указателей для структур данных файлов.

NTFS поддерживает имена файлов длиной до 255 символов и кодировку Unicode.

Структуры данных поддерживают быстрое перемещение и поиск в каталогах. '

Файловая система поддерживает сжатие и разреженные файлы.

Начиная с Windows 2000 поддерживается шифрованная файловая система (EFS).

Файловая система обеспечивает устойчивость к отказам, например к появлению поврежденных кластеров на диске или перераспределению секторов.

NTFS не имеет ограничения на длину имен 8.3, которое было характерно для MS DOS. Кроме того, обеспечивается совместимость с именами

файлов POSIX, включая точки и пробелы в начале имени. Тем не менее иногда при использовании имен, не соответствующих стандарту 8.3, возникают проблемы. Основной их причиной могут быть утилиты, не поддерживающие длинных имен, которые не соответствуют стандарту 8.3. Отдельные имена файлов NTFS могут иметь размер до 255 символов, а полный путь к файлу не должен превышать 32 767 символов.

? В NTFS используются 64-разрядные указатели файлов и теоретически может поддерживаться размер файла 264 байт.

В NTFS поддерживается несколько потоков данных для одного файла. Поток можно открыть с помощью функции Win32 API CreateFile, а имя потока в виде: ИмяПотока может быть добавлено к имени файла, например Filel: Stream25. Потоки поддерживают запись, чтение и независимую от других открытых потоков блокировку. Операционная система Windows NT для серверов Macintosh использует эту функцию при поддержке клиентов Мае, на которых файл имеет две «ветви»: ветвь данных и ветвь ресурсов.

Обратите внимание, что, хотя NTFS и поддерживает несколько потоков, множеству утилит и программ об этом ничего не известно. Таким образом, о файле, содержащем 1024 байт в обычном неименованном потоке и 1 Мбайт данных в именованном потоке, команда dir сообщит, как о файле размером 1024 байт (команда dir не поддерживает многопоточность). При копировании файлов с несколькими потоками с раздела NTFS в FAT копируется только неименованный поток, принятый по умолчанию. Данные из остальных потоков считаются потерянными.

В табл. 6.3 сравниваются FAT и NTFS.

Таблица 6.3. Сравнение файловых систем, поддерживаемых Windows NT

Окончание табл. 6.3

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

Главная файловая таблица (Master File Table – MFT; $Mft) всегда представляет собой первый файл тома NTFS. Она содержит множество записей и, как минимум, одну запись для каждого файла и каталога тома, включая запись для самой MFT. Каждая запись в MFT может иметь размер 1024–4096 Кбайт, в зависимости от размера тома, на котором размещена файловая система. Для файлов с несколькими атрибутами или чрезмерной фрагментацией может потребоваться несколько записей в MFT. Таблица MFT хранится в начале тома.

Производительность системы существенно повышается, если записи MFT хранятся в соседних кластерах диска, т.е. когда MFT не фрагментирована и занимает непрерывную область диска. Для выполнения этого условия NTFS резервирует область, которая называетсязоной MFT, в начале тома или раздела и стремится не использовать эту область ни для чего, кроме хранения записей MFT. Первые файлы и каталоги записываются сразу после MFT. Около 12% тома зарезервировано для зоны MFT. Начиная с Windows NT 4.0 SP4, в реестр добавлена специальная запись, которая позволяет управлять размером зоны MFT. Эта запись может иметь значения в диапазоне от 1 до 4, указывая размер зоны MFT от минимального (1) -до максимального (4). Программа дефрагментации указывает текущий размер зоны MFT.

Первые 24 записи в MFT зарезервированы. Некоторые записи меняют свое назначение с выходом новой версии операционной системы, как это произошло с выходом Windows 2000. В табл. 6.4 описаны различные системные файлы NTFS, которые также известны как файлы метаданных.

Таблица 6.4. Системные файлы NTFS

* Знак доллара ($) перед именем файла означает, что это файл метаданных

Файл $MftMirr содержит зеркальную копию первых 16 записей MFT и представляет собой метод обеспечения целостности тома, даже если секторы MFT окажутся поврежденными. Файл $MftMirr хранится в середине тома. Более объемные тома могут иметь более одного зеркала MFT.

Файл журнала $LogFile используется для восстановления после отказов в работе системы или возникновения неожиданных ситуаций. NTFS поддерживает транзакции и протоколирование: сначала в журнал заносятся все изменения системных метаданных и только затем проводятся изменения. Файл журнала содержит информацию для отмены и повтора операций, которая используется для восстановления после отказов в работе системы и поддержки целостности файловой системы.

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

Все операции с файлом журнала выполняются средствами службы файлового журнала NTFS, которая предоставляет собой набор процедур драйвера NTFS. Для хранения файла журнала в NTFS используется циклический буфер. В начале буфера содержится указатель на область в самом буфере, в которой должен начаться процесс восстановления. Этот указатель в файле журнала сохраняется дважды (избыточно), чтобы обеспечить возможность восстановления в том случае, если одна из областей файла журнала окажется поврежденной.

Файл $Volume содержит имя тома, дату и временную метку (указывающую на время создания тома), информацию о версии NTFS и дополнительный бит, используемый для проверки правильности завершения работы системы. Кроме того, этот бит проверяется при загрузке системы для определения необходимости запуска утилиты CHKDSK.

Файл $AttrDef содержит все атрибуты, которые поддерживаются на данном томе. Для каждого атрибута указывается различная информация, например имя атрибута, тип атрибута, минимальная и максимальная длина.

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

Файл $Bitmap представляет каждый кластер диска, на котором находится том. Каждый бит указывает занятость одного кластера диска.

Файл $Boot предназначен для хранения и защиты кода загрузчика, который всегда размещен в фиксированной области, удаленной от начала тома. При форматировании тома с использованием NTFS утилита форматирования проверяет, владеет ли файл $Boot кластерами, в которые помещен код загрузчика. Таким образом, код загрузчика защищен от перезаписи другими данными.

Файл $BadClus содержит записи для каждого поврежденного кластера на диске. Этот файл обновляется динамически; т.е. для каждого динамически обнаруженного поврежденного кластера в файл добавляется новая запись.

Файл $Secure впервые появился в Windows 2000. Файловая система NTFS поддерживает механизмы безопасности для каждого файла и каталога. До выхода Windows 2000 данные о безопасности хранились в каждой записи для файла и каталога в MFT. Поскольку множество файлов и каталогов «имели одинаковую информацию о правах доступа, такая информация часто 'дублировалась. Например, если у пользователя есть право доступа на чтение и запуск 100 файлов, формирующих приложение (например, Microsoft Office), «все эти файлы будут иметь одинаковую информацию безопасности. Начиная с Windows 2000 информация о безопасности сохраняется один раз в файле *$SeCure, и все файлы просто ссылаются на эти данные.

Файл $UpCase содержит таблицу, используемую для преобразования имен файлов и путей из нижнего регистра в верхний, а также для преобразования имен файлов в верхний регистр для приложений, которые не различают регистр в именах файлов.

Каталог $Extend впервые появился в Windows 2000 и содержит файлы, позволяющие реализовать необязательные возможности NTFS. Далее приведен перечень файлов, которые содержатся в каталоге $Extend.

Файл $0bjld содержит идентификаторы объектов для файлов и каталогов. Идентификаторы объектов используются для отслеживания файлов и каталогов при их перемещении. Дополнительная информация по этой теме приводится в разделе 6.5.15.

Файл $Quota используется для хранения информации о квотах для тех томов, где квотирование включено: Отслеживание квот рассматривается в разделе 6.5.9.

Файл $UsnJrnl содержит информацию, которая относится к изменениям в файлах и каталогах. Дополнительная информация по этой теме приводится в разделе 6.5.13.

Файл $Reparse содержит информацию обо всех файлах и каталогах, с которыми связан тег точки повторной обработки. Точки повторной обработки (reparse points) представляют собой механизм реализации символьных ссылок. Эта тема рассматривается в разделе 6.5.22.

Файловая система NTFS работает с целым числом дисковых секторов как с минимальным единичным блоком данных. Такой блок называется кластером. Размер кластера определяется при форматировании тома. Разные тома могут иметь различные размеры кластеров. Для читателей, знакомых с UNIX, можно отметить, что термин кластер в Windows аналогичен термину размер блока файловой системы в UNIX. Файловая система вычисляет размер кластера, принимая во внимание размер диска и тип используемой файловой системы. Кластер может иметь размер в диапазоне 1–64 Кбайт. Размер кластера задается при форматировании тома в виде параметра команды format или параметра утилиты управления дисками с графическим интерфейсом. Очевидно, что большой размер кластера приводит к потерям дискового пространства; например, для хранения файла размером 1 Кбайт файловой системе придется выделить кластер размером 64 Кбайт.

К кластерам относится несколько важных параметров NTFS. Первый параметр называется логическим номером кластера (logical cluster number – LCN). Файловая система NTFS делит весь диск на кластеры и назначает каждому кластеру номер, начиная с нуля. Таким образом, первый кластер будет иметь номер 0, второй кластер – номер 1 и т.д. Этот номер и называется LCN. Вторым важным параметром является виртуальный номер кластера (virtual cluster number – VCN), который указывает номер кластера внутри определенного файла. Таким образом, логический номер кластера, равный 25, указывает на 26-й (помните, что нумерация начинается с нуля) кластер тома, а виртуальный номер кластера, равный 25, указывает на 26-й кластер определенного файла.

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

Как уже отмечалось, каждый файл и каталог в NTFS имеет собственную запись в главной'таблице файлов. Эта запись иногда упоминается как запись MFT. Каждая запись MFT имеет фиксированный размер, который определяется в момент форматирования диска и находится в диапазоне 1024–4096 байт. В Windows NT 3.51 запись MFT имела размер 4 Кбайт. В Windows NT 4.0 компания Microsoft изменила минимальный размер записи, чтобы он составлял 1 Кбайт или был равен размеру кластера, в зависимости от того, что больше. Это было сделано после проведения анализа, показавшего, что записи MFT чрезмерно занимают дисковое пространство.

Запись MFT содержит стандартный заголовок, после которого идет последовательность атрибутов, сохраняемых в такой форме:

заголовок атрибута;

название атрибута;

данные атрибута.

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

Таблица 6.5. Атрибуты NTFS

Окончание табл. 6.5

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

На рис. 6.5 представлены данные файлов, сохраненные в виде нерезидентных атрибутов. В этом случае структура данных включает три элемента.

Виртуальный номер кластера (VCN), который указывает расположение кластера относительно начала файла. Например, виртуальный номер кластера, равный 0, указывает, что необходимый кластер является первым кластером атрибута файла.

Логический номер кластера (LCN), который указывает расположение кластера относительно тома или раздела. Например, логический номер кластера, равный 25, указывает, что необходимый кластер является 26-м кластером от начала тома или раздела.

Количество кластеров в определенной «цепочке», т.е. количество кластеров в непрерывной последовательности, выделенных для хранения атрибутов файла.

Рис. 6.5. Структура записи MFT

Если цепочка кластеров файла не помещается в одну запись MFT, он сохраняется в дополнительных записях MFT.

Кроме того, NTFS поддерживает несколько потоков данных. Поток, принятый по умолчанию, открывается при использовании функции CreateF'ils с именем файла в виде относительного или абсолютного пути. Указав имя файла и имя потока через двоеточие, можно открыть другой поток данных, например directorylFilel: DataStream2. Файловая система NTFS хранит эту информацию как еще один атрибут в MFT, а данные второго потока хранит в виде другого атрибута.

Это обычные файлы, которые содержат информацию о каталоге. Файловая система NTFS хранит каталоги способом, ускоряющим просмотр их содержимого. Если данные каталога не помещаются в MFT, то NTFS выделяет кластер и последовательную структуру, аналогичную области хранения данных и другим атрибутам. Все записи каталогов хранятся в деревьях В+.

Дерево В+ – это структура данных, которая поддерживает упорядоченное хранение информации и эффективна в контексте операций поиска, удаления, вставки и просмотра данных. Деревья В+ состоят из «узловых» записей, содержащих ключи, а также указателей, которые соединяют узлы дерева. Преимущество использования такой структуры данных состоит в тенденции к расширению дерева, а не к увеличению в глубину, что позволяет сохранить приемлемую производительность даже для каталогов, которые содержат большое количество записей.

Записи в каталоге хранятся в отсортированном виде. Каждая запись содержит имя файла, указатель на запись файла в MFT, а также дату/временную метку (эта информация уже хранится в записи файла MFT). Это позволяет добиться высокой производительности при просмотре содержимого каталога. Деревья В+ эффективны в аспекте количества сравнений, необходимых для поиска заданной записи каталога.

Файловая система NTFS проектировалась для обеспечения высокой производительности и надежности, с поддержкой восстановления после отказов в работе системы. Для достижения этой цели NTFS заносит в журнал $LogFile все изменения метаданных файлов перед каждой фактической попыткой их изменения. В файлах журнала содержится информация, необходимая для восстановления и повтора изменений в случае отказа в работе системы.

В Windows NT 4.0 файл журнала очищался при каждой успешной перезагрузке. В Windows 2000 записи файла журнала сохраняются в течение нескольких перезагрузок.

Безопасность NTFS унаследована от схемы безопасности Windows NT и ее объектной модели. Каждый файл или каталог имеет дескриптор безопасности, который состоит из следующих элементов:

токен безопасности, указывающий на владельца файла;

последовательность списков управления доступом (ACL), которые явно или неявно предоставляют доступ к файлу пользователям, указанным в списке;

необязательная последовательность списков управления доступом, которые явно или неявно запрещают доступ к файлу определенным пользователям; если пользователь находится в списке, разрешающем доступ, и в списке, запрещающем доступ, доступ не предоставляется.

В Windows NT 4.0 дескриптор безопасности хранился в записи MFT конкретного файла. Поскольку множество файлов и каталогов имели похожие списки управления доступом, информация о безопасности многократно дублировалась. Например, если у пользователя есть права на чтение и выполнение 100 файлов, составляющих приложение (примером может служить Microsoft Office), все файлы получат одинаковую информацию о безопасности. Начиная с Windows 2000 информация о безопасности хранится в файле $Secure, и все остальные файлы просто ссылаются на этот файл.

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

Разреженные и сжатые файлы представляют собой две совершенно разные независимые структуры, предназначенные для сокращения объема используемого дискового пространства. Файл может быть сжатым, но неразреженным и наоборот. Сжатие рассматривается в разделе 6.5.8.

Термин разреженный относится к файлам, содержащим данные, после которых идет большая область без данных, за ней небольшой фрагмент данных и т.д. Файловая система NTFS не выделяет дискового пространства для хранения пустых областей файлов. Вспомните, что виртуальный номер кластера определяет положение кластера относительно начала файла, а логический номер кластера определяет положение кластера относительно начала тома. Для разреженных файлов в NTFS выделяется виртуальный номер кластера, однако кластеры» тома не выделяются. Таким образом, логический номер кластера, относящийся к тому, для некоторых виртуальных номеров кластеров не выделяется. Если приложение пытается считать файл, NTFS заполняет участки буфера, соответствующие пустым пространствам файла, нулями. Если приложение попытается записать данные в пустые области файла, файловая система выделит необходимый объем дискового пространства.

Обратите внимание на рис. 6.6: виртуальный номер кластера определяет положение относительно начала файла, а логический номер – положение относительно начала тома.

Рис. 6.6. Выделение кластеров для разреженных файлов в NTFS

На рис. 6.6 показаны две цепочки кластеров: для неразреженного файла и для того же файла, но разреженного. Цепочка кластеров для неразреженного файла содержит три записи. Первая начинается с нулевого значения виртуального номера кластера (указывая на начало файла), расположенного в логическом кластере 125. Вместе с этой информацией указано четыре кластера, т.е. четыре кластера расположены в непрерывном участке диска. Вторая запись указывает, что следующий фрагмент файла с виртуальным номером кластера 4 (пятый кластер файла) начинается по смещению логического номера кластера, равного 251, и имеет размер в восемь кластеров. Этот кластер на рис. 6.6 показан не так, как другие кластеры, поскольку в соответствующей области файла нет данных. Последняя запись показывает, что следующий кластер файла расположен по смещению логического номера кластера, равного 1251.

Первая запись второй цепочки кластеров практически идентична. Файл по-прежнему. состоит из четырех кластеров, начиная с логического номера кластера 125. Следующая запись в цепочке указывает на последние семь кластеров файла. Виртуальный номер кластера, равный 12 (11-й кластер файла), начинается с логического номера кластера 1251. Для промежуточной области файла, не содержащей данных, запись в цепочке кластеров отсутствует.

После запроса данных из файла, NTFS обращается к записи MFT, находит соответствующий виртуальный номер кластера в файле, затем логический номера кластер и преобразует последний в смещение относительно начала тома. Если это необходимо, считываются данные из требующейся области тома. Для этого используются функции драйвера класса диска и диспетчера томов. Если логический номер кластера не выделен, в буфер данных возвращается последовательность нулей. Когда приложение записывает данные в фрагмент файла, для которого не выделен логический номер кластера, NTFS просто выделяет кластеры для этой области файла и добавляет их в цепочку кластеров. Данные затем копируются из буферов и записываются в выделенные кластеры.

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

Приложения могут указать атрибут разреженности для файла с помощью параметра FSCTL_SET_SPAR. SE функции DeviceloControl. Для получения информации о разреженности файла требуется функция GetFileAttributes.

Файловая система NTFS поддерживает сжатие файлов, если файлы размещены на томе с размером кластера менее 4 Кбайт. Данные сжимаются и ра- зархивируются «на лету» в тот момент, когда приложение вызывает функции API для чтения и записи. Сжатие может быть отключено или включено для всего тома, каталога (файлов и каталогов, расположенных в этом каталоге) или отдельного файла. И в этом случае приложения могут переопределить параметры сжатия при создании файла или каталога. Если существующий том или каталог помечается как сжатый, над уже существующими файлами никаких действий не выполняется. Параметр относится только к новым файлам и каталогам, которые будут создаваться в этом каталоге.

Сжатые файлы хранятся в цепочках длиной по 16 кластеров каждая. Файловая система NTFS берет первые 16 кластеров и пытается их сжать. Если в результате сжатия получается 15 кластеров или меньше, файл становится сжатым; в противном случае дальнейшие попытки сжатия файла не предпринимаются.

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

Рис. 6.7. Выделение кластеров для сжатых файлов в NTFS

На рис. 6.7 показаны две цепочки кластеров для одного и того же файла. В первой цепочке кластеров (в левой верхней части диаграммы) сжатие не применяется. Файл хранится в трех последовательностях длиной по 16 кластеров каждая. Первые 16 кластеров начинаются с логического номера кластера, равного 125, следующие 16 кластеров – с логического номера, равного 251, последние 16 кластеров – с логического номера, равного 1251. Файл занимает 48 кластеров тома. Во второй цепочке кластеров на рис. 6.7 использовано сжатие. Теперь файл содержит всего 12 кластеров в трех последовательностях. Первые четыре кластера начинаются с логического номера кластера, равного 125, следующие четыре кластера –1 с логического номера, равного 251, последние четыре кластера – с логического номера, равного 1251.

Получив следующий виртуальный номер кластера и количество кластеров, NTFS может определить, сжат ли файл. Сжатые данные распаковываются во временный буфер и сохраняются в кэше. При необходимости данные копируются в буфер приложения.

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

Приложения могут выбрать сжатие файлов, указав параметр FSTCL_SET_ COMPRESSION при вызове функции DeviceloControl. Для получения информации о сжатости файла применяется функция GetFileAttributes.

В Windows 2000 компания Microsoft впервые предоставила технологию, с помощью которой NTFS может отслеживать и ограничивать использование дисковых ресурсов пользователями, а также выдавать им соответствующие уведомления. Это возможности NTFS, а не Windows 2000, которые недоступны в FAT и UDF. Далее представлены особенности реализации квот.

Квоты внедряются и отслеживаются для тома и для пользователя. Все данные, связанные с квотами, хранятся системой NTFS в файле $Quota, который расположен в каталоге $Extend. Различные пользователи могут иметь разные ограничения квот. Системные администраторы не подпадают под действие квот. Более того, ограничения квот, принятых по умолчанию, относятся к новому пользователю при первом применении дисковых ресурсов.

? Системным администраторам предоставляются инструменты для управления квотами. Эти инструменты позволяют установить квоты тома в одно из трех состояний.

Квота отключена. NTFS сохраняет информацию, но не предпринимает никаких действий. Если включить квоты, сохраненная информация станет немедленно доступной для применения.

Квота включена только для отслеживания.

Квота включена для отслеживания и ограничения использования дисковых ресурсов, т.е. используется для ограничения дискового, пространства.

Как только пользователь превышает лимит предупреждения, установленный дисковой квотой, NTFS создает запись в журнале событий Windows NT. В течение часа для пользователя может быть создана только

одна такая запись, хотя превышений лимита предупреждения может быть несколько.

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

Компания Microsoft предоставляет утилиты с графическим интерфейсом, которые позволяют редактировать параметры квот. Перенос параметров квот между томами позволяет установить одинаковые параметры на всех интересующих томах. Более того, утилиты поддерживают экспорт параметров квот в различных форматах, включая CSV (comma- separated values) и текст Unicode, что предоставляет дополнительные возможности для администрирования. Затем параметры можно импортировать в другую программу, например в Excel, для последующей обработки.

В Windows 2000 появилась поддержка базовых наборов атрибутов, которые состоят из определенных пользователем метаданных, связываемых с файлом. Эти метаданные могут индексироваться средствами сервера индексации, который предоставляется в составе Windows 2000. Например, метаданные могут использоваться для обозначения автора и целевой аудитории документа. После этого можно выполнять поиск документа по определенным пользователем тегам или метаданным. NTFS рассматривает файлы как набор пар «атрибут-значение». Определенные пользователем свойства сохраняются как дополнительные атрибуты файла.

В Windows 2000 каждому пользователю, группе и компьютеру с учетной записью в домене присваивается идентификатор безопасности (security identifier – SID). Все внутренние проверки системы безопасности выполняются с помощью идентификатора безопасности. Файловая система NTFS в Windows 2000 может сканировать MFT и идентифицировать все файлы, принадлежащие определенному пользователю. Для этого существует идентификатор безопасности определенного пользователя. Одним из применений SID является удаление всех файлов после удаления идентификатора пользователя.

Файловая система NTFS в Windows NT 4.0 отслеживала списки управления доступом для файлов и каталогов. Если пользователь владел 50 файлами, одинаковые списки управления доступом создавались 50 раз, по одному для каждого файла. NTFS в Windows 2000 хранит списки управления доступом в каталоге и выполняет их индексацию. Таким образом, в описанном случае список управления доступом будет создан один раз и каждый файл будет владеть «указателем» на этот список управления доступом. В результате требования к объему свободного дискового пространства сокращаются. Кроме того, система проверки ACL реализована более эффективно.

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

Новый механизм поддерживает и другие варианты использования, например определение действий, которые пользователь может выполнять над заданным набором файлов.

Начиная с Windows 2000 файловая система NTFS предоставляет разработчикам приложений возможность надежно отслеживать изменения файлов и каталогов. Для этого используются уникальные порядковые номера (Update Sequence Number – USN). Эта необязательная служба NTFS проектировалась специально для разработчиков программ по управлению подсистемами хранения данных. Номера USN позволяют приложениям индексировать содержимое подсистемы хранения, реплицировать файлы и работать с системой управления иерархическим хранилищем данных. Для всех изменений, внесенных в файл или каталог, в файл журнала вносится соответствующая запись. Каждая запись имеет уникальный номер – USN. Такая запись создается при возникновении следующих событий:

? создание или удаление файла;

создание или удаление каталога;

изменение, удаление или добавление данных в поток данных файла (любой из именованных или неименованных потоков);

изменение (включая добавление и удаление) атрибутов файла или каталога.

Эти записи изменений хранятся в файлах журнала $Extend или $Usr Jrnl. Разреженный файл может храниться в течение нескольких перезагрузок системы. Для ограничения размера файла более старые записи удаляются блоками по 4 Кбайт. Таким образом, приложение может потенциально не получить информации обо всех происшедших изменениях. Однако предоставляемый API позволяет приложениям определять недоступность некоторых записей журнала. В подобном случае приложение может выполнить соответствующие действия, к которым относится полное сканирование всего тома. Для повышения производительности значение USN на самом деле представляет смещение в файле, указанное в соответствующей записи журнала. Если информация не была потеряна, то приложение последовательно запрашивает все записи журнала и определяет файлы и каталоги, в которые вносились изменения.

Описанная технология не только позволяет получить список изменившихся файлов и каталогов, но и указывает причину внесения изменений. Существует три типа изменений.

Изменения, внесенные приложениями.

Изменения, внесенные приложениями управления подсистемой хранения данных (например, системой управления иерархическим хранилищем) и приложениями репликации.

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

Метод определения причины изменений базируется на том, что приложения могут выбирать и игнорировать изменения определенного рода.

Приложения могут запускать службу журнала изменений, передав параметр FSCTL_CREATE_USN_JOURNAL функции DeviceloControl. Для чтения записей USN необходимо воспользоваться параметром FSCTL_QUERY_USN_ JOURNAL.

Файловая система NTFS в Windows NT обладает возможностью применять несколько потоков данных одного файла. В качестве примера программы, использующей несколько потоков данных, можно указать сервер Windows NT Macintosh. Потоки создаются с помощью функции CreateFile и удаляются функцией DeleteFile. Обратите внимание: при копировании файлов с дополнительными потоками на том с файловой системой FAT, которая не поддерживает использования Нескольких потоков, именованные потоки данных теряются.

До появления Windows 2000 не существовало способа переименования потока данных после его создания. Можно было создать новый файл с новым именованным потоком данных и скопировать содержимое старого файла в новый, включая содержимое старого именованного потока данных, но этот подход весьма неэффективен. Файловая система NTFS в Windows 2000 поддерживает функции, позволяющие приложениям переименовывать потоки данных.

Операционная система Windows 2000 поддерживает отслеживание ссылок. Ссылки могут быть ярлыками для файлов или объектами OLE (например, для документов Excel или PowerPoint), встроенными в файл. Приложение может отслеживать ссылки, даже если источник ссылки переместится в другое место. Примеры такого переноса представлены далее.

Перенос документа, являющегося источником ссылки, в пределах одного тома Windows NT.

Перенос документа, являющегося источником ссылки, между томами в пределах одного сервера под управлением Windows NT.

Перенос документа, являющегося источником ссылки, с одного сервера под управлением Windows NT на другой сервер Windows NT в пределах одного домена.

? Перенос целого тома, содержащего источник ссылки, с одного сервера под управлением Windows NT на другой сервер в пределах одного домена.

Переименование сервера под управлением Windows NT, на котором хранится источник ссылки.

Переименование документа, который является источником ссылки.

Любая комбинация перечисленных выше действий.

Все эти возможности основаны на требовании к размещению источника и точки назначения ссылки на томах с NTFS под управлением Windows 2000.

Каждый файл в Windows 2000 (и более новых версиях Windows NT) имеет необязательный уникальный идентификатор объекта (16-разрядная структура $0BJECT_1D, описанная в разделе 6.5.3). Для отслеживания файла приложение ссылается на файл по уникальному идентификатору объекта. Если ссылка больше не указывает на необходимый файл (когда файл был перемещен), операционной системой вызывается служба пользовательского режима для отслеживания ссылок. Служба методом проб и ошибок пытается найти необходимый файл, воспользовавшись идентификатором объекта.

Для программного использование идентификаторов объектов и отслеживания ссылок доступны перечисленные ниже параметры функций API.

Чтобы создать идентификатор объекта для файла или каталога, приложение должно воспользоваться параметром FSCTL_CREATE_OR_GET_ 0BJECT_ID функции управления файловой системой.

Чтобы удалить идентификатор объекта для файла или каталога, приложение должно воспользоваться параметром FSCTL_DELETE_OR_GET_ 0BJECT_ID функции управления файловой системой.

Чтобы запросить идентификатор объекта для файла или каталога, приложение должно воспользоваться параметром FSCTL_CREATE_OR_GET_ 0BJECT_ID функции управления файловой системой.

В Windows 2000 файловой системе NTFS требуется меньшее количество запусков утилиты CHKDSK, а также сокращено время работы этой утилиты. Безусловно, эффективность улучшений связана с размером тома и конкретным типом повреждения. Для томов с миллионами файлов ускорение на порядок работы утилиты CHKDSK более чем вероятно.

Операционная система Windows 2000 Server содержит интегрированную службу индексирования, которая взаимодействует со служебными утилитами. Особенности службы индексирования описаны ниже.

Доступ к функциям индексации возможен с помощью диалогового окнаНайти файлы и папки (Find files or folders) в программеПроводник (Windows Explorer).

Служба индексирования поддерживает индексирование содержимого файлов и атрибутов файлов, включая определенные пользователем атрибуты.

Служба индексирования индексирует автономные файлы, которыми управляют службы удаленных хранилищ данных (RSS).

На томах с NTFS служба индексирования использует- журнал изменений для определения, какие файлы изменились с момента последней индексации.

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

Служба индексирования может работать на томах с файловой системой FAT. Однако по сравнению с томами NTFS служба работает не так эффективно, поскольку недоступны расширенные возможности NTFS, например журнал изменений.

Начиная с Windows ХР, файловая система NTFS может работать с томами, поддерживающими только чтение. При этом сам том отмечается как предназначенный только для чтения. NTFS по-прежнему проверяет файл журнала изменений, и, если в журнале указано, что некоторые изменения необходимо провести повторно, запрос на монтирование тома завершается неудачей. Тома, предназначенные для чтения, имеют важную сферу применения, включая монтирование нескольких версий одного тома, которые созданы с помощью технологии моментальных снимков.

При фрагментации файл хранится в несоседних наборах кластеров. Файл размером 64 Кбайт будет занимать 16 кластеров, каждый из которых имеет размер 4 Кбайт. Если все кластеры будут находиться рядом, то для преобразования номера LCN файла в VCN потребуется только одна запись MFT. Когда же диск фрагментирован до такой степени, что файл хранится в 16 несоседних кластерах, в MFT будет храниться 16 записей, каждая из которых будет связывать соответствующий номер LCN с VCN. Увеличение фрагментации приводит к снижению производительности системы. Однократное позиционирование головки диска и чтение 16 кластеров выполняется намного быстрее, чем 16 позиционирований с чтением одного кластера за раз.

Фрагментация может Возникать по ряду причин. Сразу после создания NTFS компактно расположена на томе и содержит:

таблицу MFT в начале тома;

свободное пространство для расширения MFT;

системные и пользовательские файлы;

дополнительное свободное пространство.

Фрагментация возникает в результате работы файловой системы и приложений. Некоторые причины описаны ниже.

Инсталляция пакета обновлений Windows NT, в процессе которой создаются новые файлы и удаляются старые. На идеально дефрагмен- тированном диске[14] выделение новых файлов начинается с начала свободного дискового пространства. При удалении старых файлов остаются небольшие свободные области, окруженные пространством, занятым файлами.

Активная работа других приложений, например сохранение временного файла в Word или Excel, удаление старого файла и переименование временного файла с помощью имени только что удаленного файла.

Работа приложений, которая может привести к выделению дискового пространства, на самом деле не используемого приложением. Хорошим примером служит документ OLE, содержащий набор файлов Microsoft Office, например документ Word со слайдом PowerPoint и электронной таблицей Excel. При изменении одного из этих компонентов, новая версия сохраняется в конце файла, а старая отмечается как удаленная, но все еще остается внутри файла документа. Компания Microsoft предоставляет драйвер фильтрации точек повторной обработки, который поддерживает функцию NSS (Native Structured Storage – естественное структурированное хранилище) для решения этой проблемы. При этом документы Microsoft Office хранятся в различных файлах, но для приложения Office «выглядят» как один документ. Хотя эта возможность была в одной из тестовых версий Windows 2000, ее исключили из финальной версии Windows 2000[15].

Фрагментация каталогов является еще одной проблемой. Некоторые каталоги, например с файлами приложений, редко увеличиваются или уменьшаются в размерах; другие каталоги, например Мои документы или Temp, содержат постоянно меняющийся набор файлов. Если область

MFT для таких каталогов выделяется на ранних этапах работы системы, каталог будет иметь множество записей MFT, потенциально расположенных в различных областях таблицы.

В Windows NT 4.0 появилась поддержка нескольких программных интерфейсов приложений для дефрагментации. Эти интерфейсы позволяли приложениям запрашивать данные о расположении файлов и управлять ими. Интерфейсы работали как с файловой системой FAT, так и с NTFS и позволяли создавать приложения дефрагментации без тщательного изучения структуры диска. Кроме того, существуют программные интерфейсы приложений для считывания таблицы MFT в том виде, в каком она хранится на диске. Документация на такие API предоставляется на Web-узлах сторонних компаний, однако не предлагается самой Microsoft. Возможно, Microsoft планирует вносить изменения в формат и структуру интерфейсов в будущем.

В Windows 2000, Windows ХР и Windows Server 2003 компания Microsoft успешно расширила поддержку дефрагментации. Ниже описаны некоторые особенности Windows ХР и Windows Server 2003.

Поддержка дефрагментации MFT. Первые 16 записей MFT переместить невозможно, впрочем, они и без того обычно не фрагментируются. Единственным исключением является корневой каталог.

Поддержка дефрагментации дисков, размер кластеров которых превышает 4 Кбайт.

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

Дефрагментация потока данных, принятого по умолчанию, а также данных точек повторной обработки и списков атрибутов. Точки повторной обработки и списки атрибутов могут быть открыты, как и обычные именованные потоки данных.

Дефрагментация области между логическим и физическим окончаниями файла, что обозначено выделенными кластерами. Такие приложения, как приложения резервного копирования и восстановления, предварительно выделяют кластеры для файла и устанавливают действительный размер файла с помощью функции SetFileValidData. В Windows 2000 можно дефрагментировать только действительные данные

файла, а дефрагментация области между логическим окончанием файла и конечными кластерами, выделенными файлу, не поддерживается.

Предотвращение дефрагментации открытых файлов, которое возможно, если приложения открывают файлы, указывая новый параметр FSCTL(FSCTL_MARK_HANDLE с параметром FSCTL_MARK_HANDLE_PROTECT_ CLUSTERS).

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

В Windows 2000 поставляется шифрованная файловая система (Encrypted File System – EFS), позволяющая закрыть основную брешь безопасности Windows. Файловая система NTFS обеспечивает безопасность, если приложения получают доступ к файлам средствами самой NTFS. Однако злоумышленник, получивший физический доступ к серверу, может перезагрузить компьютер с помощью другой операционной системы и получить доступ к диску в «непосредственном режиме» с помощью другой файловой системы. Для исключения подобной возможности в Windows 2000 появилась EFS, которая обеспечивает шифрование данных перед записью на жесткий диск. Шифрованная файловая система может быть включена для отдельных каталогов или отдельных файлов. С другой стороны, версии Windows 9х позволяли использовать шифрование для отдельных разделов.

В шифрованной файловой системе используется симметричная и асимметричная криптография. Архитектура файловой системы поддерживает и другие алгоритмы шифрования. Данные могут быть дешифрованы с помощью того же ключа, так как DES (Data Encryption Standard) – это симметричный шифратор.

На рис. 6.8 показано, что данные шифруются с помощью случайно сгенерированного 12-разрядного ключа. Для шифрации используется один из вариантов алгоритма DES. На первом этапе показано шифрование данных файла с помощью случайно сгенерированного ключа, на втором – шифрование случайно сгенерированного ключа с помощью открытого ключа пользователя. После этого ключ сохраняется в поле Data Decryption в атрибутах файла. Это поле используется для дешифрации, как отмечается далее в этом разделе. Наконец, случайно сгенерированный ключ шифруется еще раз с помощью открытого ключа агента восстановления. Агентом может быть системный администратор или другой пользователь, обладающий соответствующими полномочиями. Генерация поля Data Recovery показана на третьем этапе (см. рис. 6.8). Поле Data Recovery предоставляет вторичный способ получения данных, если пользователь окажется недоступным или вдруг решит сделать данные невосстановимыми.

Рис. 6.8. Схема шифрации файлов в EFS7

При чтении файла считывается содержимое поля Data Decryption и дешифруется закрытым ключом пользователя (первый этап на рис. 6.9) для получения 128-разрядного ключа, необходимого для дешифрации данных файла. После этого данные дешифруются с помощью 128-разрядного ключа (второй этап). На рис. 6.9 приведен необязательный третий этап, на котором восстанавливается 128-разрядный ключ шифрации/дешифрации. Для этого проводится дешифрация поля Data Recovery (а не поля Data Decryption).

На рис. 6.10 показана архитектура EFS. Драйвер EFS – это драйвер фильтрации файловой системы, который расположен уровнем выше NTFS. (Шиф-

7Фактически стандартом асимметричного шифрований ключа является технология RSA, а стандартом симметричного шифрования – DESX. Более подробная информация представлена на Web-узле по адресу: http://viwv. raasecurity.com/rsalab8/faq/3-l-l. html.

Рис. 6.9. Схема дешифрации файлов в EFS

рованная файловая система не поддерживается другими файловыми системами, включая FAT.) Драйвер обрабатывает рабочие вызовы, которые называются FSRTL (File System Run-Time Library) и используются для чтения, записи и открытия/закрытия зашифрованных файлов. Эти вызовы применяют средства NTFS для чтения или записи метаданных, относящихся к шифрованию, например полей Data Decryption и Data Encryption.

Служба EFS обеспечивает работоспособность функций шифрации/де- шифрации и генерацию шифрованных ключей с помощью инфраструктуры API шифрования, входящей в Windows NT. Служба EFS взаимодействует с драйвером EFS с помощью локальных вызовов процедур (LPC), предоставляемых операционной системой.

В отличие от Windows Server 2003, операционная система Windows 2000 не поддерживает использование шифрованного файла несколькими пользователями. Тем не менее симметричный ключ можно зашифровать несколько раз открытыми ключами нескольких пользователей.

Программный доступ к шифрованным файлам обеспечивается функциями API EncryptFile и Decrypt File.

Рис. 6.10. Архитектура EFS

Файловая система NTFS поддерживает два типа ссылок: модифицируемые (soft) и закрепленные (hard). Обратите внимание, что в Windows Server 2003 закрепленные ссылки поддерживаются только для файлов, а модифицируемые – только для каталогов. Модифицируемые ссылки реализуются с помощью точек повторной обработки (reparse points). Эта технология рассматривается в разделе 6.5.22.

Закрепленные ссылки позволяют одному файлу иметь несколько имен путей. Использование таких ссылок возможно только для файлов и не поддерживается для каталогов. Закрепленные ссылки могут применяться, например, в нескольких компилируемых проектах, где изменения в ряде файлов заголовков должны отражаться во всех проектах одновременно. Альтернативой закрепленным ссылкам может служить использование нескольких копий файла. Закрепленные ссылки реализуются с помощью одной записи MFT, в которой размещено несколько атрибутов с именем файла. Вызов CreateHardLink из Win32 API позволяет создать закрепленные ссылки и в качестве параметров принимает путь к существующему файлу и имя еще не существующего файла.

Закрепленные ссылки поддерживаются в NTFS еще со времен Windows NT 3. x, так как требовались для подсистемы POSIX. Последним изменением стало предоставление открытого доступа к API для создания и удаления закрепленных ссылок. Файлы удаляются после удаления последнего имени, связанного с этим файлом. Другими словами, если файл имеет две закрепленные ссылки, а именно linkl. doc и link2. doc, удаление linkl. doc не приведет к удалению link2. doc.

Это относительно новая функция NTFS и-подсистемы ввода-вывода Windows NT. Точки повторной обработки представляют способ реализации следующих функций:

точки монтирования томов;

точки соединения каталогов;

хранилище SIS (Single Instance Storage);

удаленное хранилище (HSM).

В этом разделе подробно рассматривается архитектура точек повторной обработки. В разделах 6.5.22.1–6.5.22.4 описываются методы применения точек повторной обработки, показанных ранее.

Обратите внимание, что в этом разделе точки повторной обработки рассматриваются как неотъемлемая часть файловой системы NTFS. Хотя FAT не поддерживает точек повторной обработки, независимый поставщик программного обеспечения или компания Microsoft могут создать файловую систему, которая отличается от NTFS, но поддерживает точки повторной обработки. Такая задача далеко не тривиальна, однако использовать при этом три перечисленных ниже компонента обязательно.

Файловая система, например NTFS.

Подсистема ввода-вывода и Win32 API.

Утилиты и инструменты.

Компания Microsoft провела необходимую работу во всех трех областях; таким образом, новая файловая система вполне может содержать точки повторной обработки.

Точки повторной обработки – это объект каталога или файла NTFS. Приложение может создавать их, управлять ими и удалять их с помощью функций Win32 API в целом и функций CreateFile, ReadFile и WriteFile в частности. Набор функций Win32 API предоставляет приложению возможность создания определенных пользователем атрибутов для файлов и каталогов. Точки повторной обработки можно воспринимать как определеннее пользователем атрибуты, которые обрабатываются особым образом. Это подразумевает обеспечение уникальности некоторых фрагментов объекта атрибута и обработку в подсистеме ввода-вывода. Независимый поставщик программного обеспечения должен создать:

Рис. 6.11. Тег точки повторной обработки

ш утилиты пользовательского режима, позволяющие создавать и удалять точки повторной обработки, а также управлять ими;

драйвер фильтрации файловой системы, который реализует функции, относящиеся к точкам повторной обработки.

Точки повторной обработки состоят из компонентов, описанных ниже.

Уникальный тег размером 32 бит, назначаемый Microsoft. Независимые поставщики программного обеспечения могут запросить назначение уникального тега. Тег точки повторной обработки обладает хорошо определенной структурой (рис. 6.11).

Флаг М указывает, предназначен ли тег для драйвера устройства Microsoft.

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

Флаг N указывает, является ли файл или каталог псевдонимом другого файла или каталога.

Зарезервированные флаги.

Фактическое значение 16-разрядного тега.

Двоичный объект данных размером 16 Кбайт. Файловая система NTFS делает этот объект доступным драйверу устройства стороннего разработчика в качестве элемента операции ввода-вывода, проводимой с точкой повторной обработки.

Рис. 6.12. Архитектура точек повторной обработки

На рис. С. 12 показана последовательность операций и реализация точек повторной обработки. Предположим, у пользователя есть необходимые права для выполнения запрошенной операции. Чтобы не усложнять рис. 6.12, на нем представлен только один драйвер фильтрации файловой системы.

Далее приведена последовательность действий для реализации функций точек повторной обработки, которые показаны на рис. 6.12.

С помощью подсистемы Win32 приложение запрашивает открытие файла.

После определенных проверок подсистема Win32 направляет запрос выполняемому модулю NT.

Диспетчер ввода-вывода Windows NT создает пакет запроса ввода-вывода (IRP) с запросом на открытие (IRP_MJ_OPEN). Обычно этот запрос переходит драйверу NTFS. Так как в процессе участвует драйвер фильтрации, например драйве]) фильтрации точки повторной обработки, диспетчер ввода-вывода отправляет запрос драйверу фильтрации, предоставляя ему возможность предварительной обработки пакета IRP до того, как пакет попадет на обработку драйверу NTFS.

Драйвер фильтрации точки повторной обработки указывает процедуру завершения в своем фрагменте пакета IRP и отправляет пакет драйверу NTFS.

Пакет IRP достигает файловой системы. Она принимает запрос IRP_MJ_ OPEN, находит файл или каталог и отмечает тег точки повторной обработки, который связан с этим каталогом или файлом. Файловая система NTFS размещает тег точки повторной обработки и данные в пакете IRP и неудачно завершает обработку пакета IRP с возвратом специального кода ошибки.

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

Файловая система NTFS завершает повторную операцию IRP. Типичным примером может быть изменение пути и успешное завершение обработки запроса. Диспетчер ввода-вывода завершает обработку запроса открытия; после этого каждый драйвер фильтрации файловой системы еще раз вызывается через процедуру завершения. Драйвер отмечает, что запрос на открытие завершился успешно, и выполняет необходимую последовательность действий. Наконец обработка пакета IRP завершается, и приложение получает управление для обработки файла.

Если ни один из драйверов фильтрации не распознал тег повторной обработки, запрос на открытие файла или каталога завершается неудачно.

Некоторым приложениям требуются точки повторной обработки; в то время как другие приложения совершенно в них не нуждаются. Приложению Microsoft Office, открывающему документ Word, PowerPoint или Excel, могут не понадобиться функции точки повторной обработки, перенаправляющей запрос на другой том. Однако некоторые приложения, рекурсивно обрабатывающие дерево каталогов, должны «знать» о возможности создания цикличных путей.

Приложения могут подавлять функции точек повторной обработки. Для этого запросам CreateFile, DeleteFile и RemoveDir необходимо передать параметр FILE_0PEN_REPARSE_P0INT. Вызов функции GetVolumelnformation возвращает флаг FILE_SUPPORTS_REPARSE_POINTS. Вызовы GetFileAttributes, FindFirstFile и FindNextFile возвращают флаг FILE_ATTRIBUTE_REPARSE_

POINT для индикации наличия точки повторной обработки. Точки повторной обработки создаются с помощью параметра FSCTL_SET_REPARSE_POINT функции DeviceloControl.

Операционная система Windows 2000 позволяет приложениям перечислять все точки повторной обработки и/или точки монтирования, расположенные в пределах тома. Для этого NTFS хранит информацию о точках повторной обработки (включая точки монтирования) в файле $Extend$Reparse. Все точки повторной обработки на томе NTFS индексируются в файле $Index, который находится в каталоге $Extend. Таким образом, приложение может быстро индексировать все эти точки.

Операционная система Windows NT 4.0 для монтирования тома или раздела требовала использования буквы диска. Это ограничение не позволяло операционной системе иметь больше 26 томов. Операционная система Windows 2000 позволяет монтировать том без буквы диска. Однако существуют некоторые ограничения:

том может быть смонтирован только на локальный каталог; другими словами, том нельзя смонтировать на каталог сетевого ресурса;

s том может быть смонтирован только на пустой каталог;

пустой каталог должен располагаться в разделе NTFS (поскольку только NTFS поддерживает точки повторной обработки).

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

В состав пакета Windows SDK включены программные интерфейсы приложений, которые поддерживают добавление и изменение точек монтирования томов. Некоторые функции перечислены ниже.

GetVolumelnformation может использоваться для получения информации о томе, включая индикацию поддержки точек монтирования.

ш FindFirstVolumeMountPoint и FindNextVolumeMountPoint используются для поиска точек монтирования томов.

FindVolumeMountPointClose освобождает ресурсы, полученные функциями FindFirstVolumeMountPoint и FindNextVolumeMountPoint.

GetVolumeNameForMountPoint возвращает соответствующее имя тома, в которое преобразуется имя точки монтирования.

Точки соединения каталогов связаны с точками монтирования томов. Разница между ними заключается в том, что точка монтирования «превращает» каталог в новый том, а точка соединения каталогов превращает каталог в другой каталог, который расположен на том же локальном томе, что и точка соединения каталогов. Точки соединения каталогов могут создаваться с помощью утилиты linkd. exe или утилиты junction. ехе, которая поставляется в наборе Resource Kit для Windows 2000 или в комплекте самой операционной системы.

В Windows 2000 поддерживается технология SIS (Single Instance Storage) для служб удаленной установки (RIS). Службы позволяют создавать загрузочные образы и образы приложений, которые хранятся на сетевых ресурсах и доступны для клиентов. Зачастую клиенты создают несколько образов, например один для отдела проектирования, другой для бухгалтерии, третий для отдела кадров и т.д. Многие файлы дублируются в нескольких образах.

Применение символических ссылок для одновременного использования файла в нескольких установочных образах связано с опасностью переноса изменений с одного образа на все остальные. Представьте файл. ini, который совместно используется тремя отделами. Если проектный отдел внесет изменения в этот файл, установочные образы остальных отделов также будут содержать эти изменения. Технология SIS предоставляет способ использования единственной копии там, где это возможно. В то же время, если понадобится, копию можно автоматически разделить на несколько разных версий.

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

Далее перечислены основные возможности SIS.

Обнаружение идентичных файлов, которые хранятся в нескольких экземплярах.

Копирование файлов, которые хранятся в нескольких экземплярах, в специальное хранилище. Эта функция напоминает службу HSM, но файл всегда хранится в специальном хранилище SIS на диске.

Реализация ссылок SIS для этих файлов. Ссылки SIS – это файлы-»за- глушки» на месте оригинального файла. Файл-заглушка имеет точку повторной обработки, которая указывает на копию файла в хранилище SIS.

Рис. 6.13. Архитектура Single Instance Storage

На рис. 6.13 демонстрируется архитектура SIS со следующими компонентами:

Хранилище SIS

драйвер фильтрации SIS;

программные интерфейсы приложений SIS;

анализатор SIS.

Служба SIS обеспечивает работу защищенного хранилища данных, которое содержит все файлы, обозначенные в качестве кандидатов SIS. Преимущество такой схемы состоит в исключении проблем, связанных с удалением, перемещением и переименованием общих файлов. Недостаток такого подхода связан с накладными расходами операции копирования. Файлы в общем хранилище содержат обратный указатель на файлы, которые они представляют.

Драйвер фильтрации файловой системы обеспечивает работу точки повторной обработки, которая предоставляет связь между файлом и копией в общем хранилище SIS. Драйвер SIS реализует две важные функции управления вводом-выводом (IOCTL).

Первая функция – SIS_COPYFILE – копирует файл в общее хранилище SIS и превращает исходный файл в ссылку; этот файл-ссылка на самом деле

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

Второй важной функцией IOCTL, реализованной драйвером SIS, является SIS_MERGE_FILES, которая используется для слияния двух файлов. Это защищенная функция вызывается только анализатором SIS пользовательского режима.

Кроме определенных функций IOCTL драйвер SIS отвечает за реализацию ссылок SIS (они напоминают символьные ссылки), позволяющих приложению ссылаться на файл. При этом драйвер обеспечивает работу функций, предоставляющих данные файла из файла в общем хранилище SIS.

Анализатор SIS (SIS Groveler) отвечает за сканирование всех файлов на томе и определение дублированных файлов. Анализатор использует возможности драйвера SIS для перемещения обнаруженных дублированных файлов в общее хранилище SIS. Для обнаружения изменений в файлах применяется журнал изменений NTFS. Как только полное сканирование диска завершено, журнал изменений повышает эффективность работы анализатора и ограничивает сканирование только измененными файлами.

Служба SIS не. управляет всеми томами. При запуске SIS все тома NTFS сканируются на предмет наличия папки общего хранилища SIS. Служба подключается к томам, на которых расположена эта папка. Как уже отмечалось, папка представляет собой общее хранилище SIS, создаваемое при инсталляции этой службы.

Когда приложение открывает файл, на самом деле может открываться лишь файл-ссылка SIS, в то время как реальное содержимое файла будет получено из общего файла в хранилище SIS. Рассмотрим пример, в котором файл. ini совместно используется тремя отделами: проектным, отделом кадров и бухгалтерией. В общем хранилище будет сохранена единственная копия файла. ini, и в образах будут сохранены три ссылки на этот файл. Предположим, что в проектном отделе принято решение изменить значение параметра, сохраненного в файле. ini. Служба SIS обеспечивает изолированность других отделов от этого изменения.

Служба SIS изолирует отделы посредством копирования при закрытии, когда приложение записывает изменения в объект, который воспринимается как файл. ini для проектного отдела, и закрывает файл после внесения необходимых изменений. Причина использования операции копирования при закрытии, а не при записи, состоит в статистике, согласно которой большой процент операций записи приводит к перезаписи всего файла, а не определенного его фрагмента. Копирование при записи в такой ситуации приведет к ненужному копированию данных из существующего файла с последующей перезаписью только что скопированных данных. Если целый файл не записывается сразу, не изменившиеся фрагменты файла извлекаются из существующего общего хранилища SIS и добавляются к только что записанным фрагментам файла.

Служба SIS предоставляет API для приложений резервного копирования. Это сделано для того, чтобы все ссылки SIS не стали полноценными файлами при копировании на резервный носитель. Таким образом обеспечивается резервное копирование только одной копии данных из общего хранилища SIS с возможностью 'восстановления всех файлов ссылок и данных.

Технология управления иерархическим хранилищем (Hierarchical Storage Management – HSM) более подробно рассматривается в главе 7. Здесь же достаточно отметить, что такие приложения с поддержкой HSM могут быть созданы поверх механизма точек повторной обработки, описанного в разделе 6.5.22.3. По сути, реализация HSM от Microsoft – пример такого использования точек повторной обработки. Служба HSM переносит файлы с дисков на другие носители, оставляя вместо них файлы-заглушки с точками повторной обработки. Как только приложение открывает этот файл, механизм точек повторной обработки вызывается для незаметного извлечения данных с другого носителя.

Оглавление книги