6.1 Диски, разделы и тома

Термин диск используется при описании такого физического носителя, как накопитель IDE или SCSI, а также сменных носителей, например накопителей USB, компакт-дисков и DVD. Логически диск состоит из кластеров, которые характеризуются размером, например 512, 1024, 4096 байт. Термин диск всегда используется при ссылке на физический объект, который можно увидеть и взять в руки. С другой стороны, термины раздел и том, которые описываются в следующих абзацах, представляют собой логические концепции.

В контексте администрирования некоторые диски (но не все) могут быть разделены на несколько логических областей, которые называются разделами (partitions). Каждый раздел может содержать указанный объем данных, и это значение представляет собой интегральное количество кластерных единиц. Например, диск объемом 80 Гбайт может быть разбит на два раздела, один из которых предназначен для установки файловой системы и системных утилит, а второй – для хранения пользовательских данных. Еще одна причина выделения небольшого раздела на корпоративных сервера^ связана с установкой диагностических утилит.

Рис. 6.1. Диски, разделы и тома

Том (volume) – это набор, состоящий из одного или нескольких разделов. Комбинация разделов может быть подобрана для обеспечения быстродействия, объема, целостности данных или сочетания этих параметров. Например, два раздела могут быть объединены для создания тома большего объема или два раздела одинакового размера могут составлять единый зеркальный том, в котором данные дублируются на каждый из разделов. Такие методы комбинации разделов рассматриваются в главе 9, посвященной массивам RAID. Обратите внимание: комбинирование разделов имеет ряд особенностей, которые зависят от типа диска и версии Windows; более подробно они рассматриваются далее.

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

На рис. 6.1 показана схема NTFS тома V1, который, в свою очередь, состоит из разделов D1-P1 и D2-P2. Кроме того, NTFS установлена на томе V2, который создан из зеркальных разделов D1-P2 и D2-P1 (при этом разделы должны быть одинакового размера). Для обозначения другого метода формирования тома V2 связь между томом и разделами показана штрих- пунктирной линией. Файловая система FAT установлена на томе V3, который состоит из одного раздела D3-P1. Диск D1 разбит на два раздела: D1-P1 и D1-P2. Диск D2 также разбит на два раздела: D2-P1 и D2-P2. Диск D3 имеет только один раздел – D3-P1. Обратите внимание, что рис. 6.1 приведен в качестве примера и не описывает всех возможных способов создания томов.

Учитывая базовые идеи, лежащие в основе файловых систем, можно обратиться к деталям. В частности, описанию раздела как набора дисковых кластеров не хватает ряда важных подробностей, например: каким образом операционная система собирает данные на нескольких разделах, существующих на определенном диске, и в каком месте начинается и заканчивается определенный раздел. Ответы на эти вопросы требуют более подробного описания, которое приводиться в разделах 6.1.1 и 6.1.2. Кроме того, разделы на базовых дисках иногда в шутку называют «жесткими» разделами, а разделы на динамических дисках – «мягкими» (об этом речь идет далее в главе). Эти названия отражают неизменность размера жестких разделов (их невозможно увеличить или уменьшить) и возможность изменения размера мягких разделов, даже если они активно используются в текущий момент времени.

Следует упомянуть еще одну особенность. В этой книге рассматривается иерархия, в которой диски делятся на разделы, а разделы составляют тома. Но в некоторых книгах термины том и раздел взаимозаменяемы, особенно если предполагается, что том состоит из одного раздела. Более того, в некоторых книгах взаимозаменяемыми являются термины раздел и диск. Читая эту книгу, помните о трехуровневой иерархии: физические диски делятся на логические элементы, которые называются разделами, а разделы, в свою очередь, определенным образом формируют другие логические элементы, которые называются томами. Файловая система. всегда взаимодействует непосредственно с томами.

6.1.1 Базовые диски

Идея разделения рабочего пространства дисков существует уже довольно давно. Термин базовый диск (basic disk) впервые появился в Windows 2000 и описывал диски, в которых для предоставления информации о разбивке диска на логические разделы применялись устаревшие технологии DOS.

Первый физический сектор на каждом диске – как базовый, так и динамический – имеет важнейшее значение. Этот сектор содержит структуру данных, которая называется главной загрузочной записью (Master Boot Record – MBR) и предоставляет информацию об организации диска, а также участвует в загрузке компьютера. Независимо от операционной системы, запись MBR одинакова для всех персональных компьютеров. Она может иметь размер до 512 байт и включает в себя четыре элемента.

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

Уникальный номер размером 4 байт, который называется сигнатурой диска. Сигнатура всегда расположена со смещением 0x01В8 (с начала сектора) и используется в качестве индекса в системном реестре для сохранения и получения информации о диске.

Таблица разделов, которая может содержать до четырех записей. Первая запись всегда расположена со смещением 0x01 BE. Каждая запись имеет размер ровно 16 байт. Один из описанных в таблице разделов отмечен как активный. С этого раздела загружается операционная система. Первый сектор каждого раздела называется загрузочным сектором тома (volume boot sector – VBS) и по своей структуре напоминает MBR. Разница между ними заключается в том, что запись MBR одна на весь диск, а загрузочный сектор существует у каждого тома. Таким образом, один физический диск может иметь несколько загрузочных секторов тома. Каждый загрузочный сектор диска содержит информацию о томе, например размер, количество секторов и метку. Кроме того, загрузочный сектор тома содержит код загрузки операционной системы, который загружается кодом раздела MBR.

Маркер завершения MBR, который всегда равен 0х55АА.

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

Базовые диски в полной мере поддерживаются в Windows 2000, Windows ХР и Windows Server 2003. Хотя эта поддержка необходима, она не лишена определенных недостатков.

Одна из проблем состоит в том, что упомянутые системы не поддерживают создания сложных томов на основе разделов базовых дисков. Под термином сложный том подразумевается том, состоящий из нескольких разделов различных базовых дисков. Примером служит том, состоящий из двух разделов различных базовых дисков для получения единого тома большего объема. В Windows NT 4.0 такие тома называются составными (spanned). Операционные системы Windows 2000 и Windows Server 2003 поддерживают уже существующие составные тома на основе базовых дисков, однако создание новых составных томов на основе базовых дисков не поддерживается.

Устаревшие составные тома, которые создавались в более ранних версиях Windows NT (до Windows 2000), могут быть импортированы в Windows 2000, Windows ХР и Windows Server 2003.

Базовые диски обладают определенными недостатками. Например, они весьма чувствительны к повреждению первого сектора, который содержит запись MBR. Только аппаратные (а не программные) массивы RAID позволяют обойти это ограничение. Массивы RAID рассматриваются в главе 9. Данные записи MBR не дублируются в программных системах RAID, и для этого есть свои причины: если система загружается и получает доступ к записи MBR, драйвер' программного решения RAID еще не загружен, поэтому не сможет помочь в решении проблем с повреждением записи MBR.

Еще один недостаток базовых дисков – необходимость перезагружать компьютер при изменении конфигурации разделов.

6.1.2 Динамические диски

Операционная система Windows 2000 ввела в обиход концепцию динамических дисков (dynamic disks). Динамические диски предназначены для преодоления недостатков базовых дисков.

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

Как показано на рис. 6.2, а, каждый динамический диск поддерживает базу данных объемом 1 Мбайт; речь идет о базе данных диспетчера логических дисков (logical disk manager – LDM). Чтобы предотвратить повреждение данных (например, вследствие работы устаревшей утилиты или в результате вмешательства другой операционной системы), все динамические диски содержат запись MBR, как и базовые диски. Для динамических дисков, которые не содержат файлов операционной системы, запись MBR создается так, чтобы охватить один раздел, занимающий весь физический диск.

Вспомним понятия загрузочного (boot) и системного (system) разделов в Windows NT. Загрузочный раздел содержит файлы операционной системы, например каталог WinNT. Системный раздел содержит загрузочный код. Поскольку загрузочный код Windows NT не поддерживает динамических томов, запись MBR иногда (когда диск содержит системный раздел) создается таким образом, чтобы был обнаружен один раздел и загрузочный код был бы доступен для обнаружения и запуска.

Рис. 6.2. Разбивка динамических дисков (а); база данных диспетчера логических дисков, зеркально отраженная в пределах дисковой группы (б)

Динамические диски организованы в группы, но диспетчер логических дисков поддерживает только одну дисковую группу. Имя дисковой группы, принятой по умолчанию (и единственной поддерживаемой), создается с помощью добавления значения dgO в конец имени компьютера. Как показано на рис. 6.2, б, эта база данных содержит информацию обо всех динамических дисках в пределах группы, что предоставляет возможность защиты данных. Здесь показано два диска, входящих в дисковую группу, хотя их может быть и больше. База данных содержит не только данные об организации дисков, но и подробную информацию о монтировании томов, т.е. о букве диска или о каталоге, в котором монтируются тома на данном диске.

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

Хотя динамические диски обладают массой преимуществ для семейства Windows NT, они не лишены некоторых недостатков. Основные из них описаны ниже.

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

Динамические диски не поддерживаются некоторыми портативными компьютерами и сменными носителями, например дисками Iomega Jazz или сменными жесткими дисками с интерфейсом 1394/USB.

Система Microsoft Cluster Server не поддерживает динамические диски, подключенные к совместно используемой кластером шине SCSI, если не установлен менеджер VERITAS Volume Manager. Можно сделать предположение, что для этого существуют причины как технического, так и юридического характера. Достаточно вспомнить, что только диспетчер Volume Manager компании VERITAS поддерживает несколько дисковых групп. Кластеры часто используются в режиме «активный- активный». Если рассмотреть наиболее простую схему кластера, включающего в себя два узла, типичным решением будет разделение дисковых ресурсов на две группы и назначение каждой группы отдельному узлу. Если работа одного узла будет нарушена, дисковая группа этого узла перейдет под управление другого узла. Таким образом, требуется наличие двух дисковых групп, а значит, поставляемый в комплекте с системой диспетчер логических дисков (LDM), поддерживающий только одну дисковую группу, не сможет справиться с описанной ситуацией.

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

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

Операционные системы Windows 2000 и Windows Server 2003 поддерживают как базовые диски, так и преобразование базовых дисков в динамические. Тем не менее преобразование имеет некоторые особенности, поэтому перед ним желательно провести резервное копирование, удалить все данные и разделы с диска, преобразовать «пустой» диск в динамический, реорганизовать диск и восстановить данные из резервной копии. Если выполнить обычное преобразование базового диска в динамический, не все преимущества динамических дисков могут оказаться доступными; например, если динамический диск создан на основе базового, динамическое изменение размеров разделов может оказаться недоступным.

 

6.2 Тома и диспетчеры томов

Как уже отмечалось, том – это логический компонент, включающий в себя дисковые разделы. Эти разделы могут быть реализованы на динамических или базовых дисках. Тома в семействе Windows Server внедряются с помощью драйвера устройства, который называется диспетчер томов. Диспетчеры томов и их место в стеке подсистемы хранения данных рассматриваются в главе 1. В этом разделе основное внимание уделяется возможностям томов в операционных системах, появившихся после Windows 2000; в частности, рассматриваются три диспетчера томов.

Диспетчер FtDisk, предоставляемый в Windows 2000 и Windows Server 2003. В Windows NT 4.0 драйвер FtDisk загружался только по требованию, поскольку работал исключительно с расширенными функциями томов^ нацример обеспечением устойчивости к ошибкам. B. Windows 2000 FtDisk драйвер загружается по умолчанию, поскольку обрабатывает все тома базовых дисков.

Диспетчер LDM (Logical Disk Manager), который предоставляется в Windows 2000 и Windows Server 2003.

Диспетчер LVM (VERITAS Logical Volume Manager), предлагаемый компанией VERITAS в качестве платной системы; LVM расширяет базовые возможности LDM.

*

Эти диспетчеры томов обеспечивают перечисленные ниже возможности.

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

Защита данных путем обеспечения их избыточности (с помощью одной из технологий массива RAID, рассматриваемых в главе 9) или посредством их сохранения вместе с контрольной суммой.

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

В табл. 6.1 приведены возможности каждого диспетчера томов в Windows 2000 и Windows Server 2003.

Таблица 6.1. Возможности диспетчеров томов

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

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

Драйвер DMIO (dmio. sys) является аналогом диспетчера FtDisk и реализует возможности диспетчера томов для стандартных операций чтения и записи данных, размещенных на дисковых разделах. Кроме того, DMIO создает объекты устройств томов. Этот драйвер имеет меньший размер, поскольку не содержит кода для чтения и записи базы данных LDM или обработки LDM в дисковом формате. Соответствующий драйвер LVM называется VxIO.

Драйвер DMBoot (dmboot. sys) поддерживает только считывание базы данных LDM. Он загружается только после того, как драйвер DMLoad (dmload. sys) обнаружит более одного динамического диска. Оба драйвера используются только в процессе загрузки. Соответствующие драйверы LVM называются VxBoot и VxLoad.

При преобразовании базового диска в динамический все старые компоненты преобразуются в новые (табл. 6.2).

Таблица 6.2. Терминология томов в Windows NT 4.0 и Windows 2000

* Массивам RAID посвящена глава 9.

В Windows 2000 методы управления томами были существенно изменены. Например, Windows 2000 не только аннулирует ограничение в 26 томов, но и позволяет динамически добавлять/удалять тома, не перезагружая систему. Для реализации таких изменений в управлении томами были введены два новых компонента – диспетчер разделов и диспетчер монтирования. Новые возможности по управлению томами, а также эти два диспетчера описаны в разделах 6.2.1–6.2.4.

6.2.1 Диспетчер разделов

Диспетчер разделов – это драйвер в Windows 2000 и Windows Server 2003. Он представляет собой драйвер фильтрации верхнего уровня (драйверы фильтрации рассматриваются в главе 1), который регистрируется в подсистеме Windows NT Plug and Play и запрашивает уведомление о создании новых объектов устройств в драйвере класса диска.

Диспетчер разделов взаимодействует с диспетчерами томов посредством закрытого интерфейса и передает диспетчерам томов уведомления о создании устройств. Как только диспетчер томов обнаруживает, что доступны все разделы, формирующие том, он создает объект устройства, представляющий том. Кроме того, диспетчер разделов уведомляет подсистему РпР об удалении объекта устройства или раздела (например, когда выполняется удаление раздела). Диспетчер разделов сообщает диспетчерам томов о динамическом создании и удалении разделов. Более подробно он рассматривается в разделах 6.2.3 и 6.2.4.

6.2.2 Диспетчер монтирования

Диспетчер монтирования – это драйвер, который появился в Windows 2000 и доступен в Windows Server 2003 и Windows ХР. Диспетчер монтирования Windows NT (mountggr. sys) предоставляет возможности для управления хранилищем данных на базе томов. К этим возможностям относятся:

монтирование томов;

размонтирование томов;

отслеживание точек монтирования томов и букв дисков в файле базы данных, который называется: $MountMgrRemoteDatabase и находится в корневом каталоге каждого тома NTFS;

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

Неудивительно, что диспетчер монтирования зависит от подсистемы Plug and Play, так как требует уведомлений о событиях, которые соответствуют активизации и отключению тома. При монтировании тома диспетчер монтирования «консультируется» с соответствующим диспетчером тома через закрытый интерфейс. Если том расположен на базовом диске, применяется диспетчер томов FtDisk, который обращается к системному реестру для предоставления соответствующей буквы диска. Если том находится на динамическом диске, используется диспетчер томов LDM, который обращается к данным точки монтирования, содержащимся в базе данных LDM динамического дис. ка.

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

Диспетчер монтирования отвечает, за назначение букв дисков томам на базовых дисках (но только тех, которые появились после запуска системы). Диспетчер монтирования назначает буквы диска начиная с буквы С: в соответствии с приоритетами. Устойчивые к ошибкам (устаревшие) наборы томов Windows NT 4.0 имеют наивысший приоритет, после чего следует основной раздел на фиксированном диске и сменные диски (Jazz, USB). После сменных дисков буквы назначаются накопителям на компакт-дисках. Как только все эти устройства получают буквы дисков начиная с А:, буквы назначаются томам на гибких дисках. Накопители на компакт-дисках получают буквы начиная с D:.

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

Операциями диспетчера монтирования можно управлять из командной строки с помощью утилиты mountvol. exe. В Windows Server 2003 возможности диспетчера монтирования были обновлены, поэтому приложения могут отказаться от монтирования томов, которые ранее никогда не монтировались в этой системе. Это слабая попытка обеспечить функции таблицы монтирования UNIX. Смысл нововведения – избежать возможного повреждения тома, если он становится доступен Windows по ошибке.

6.2.3 Дерево устройств для томов базовых дисков

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

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

Обратите внимание на рис. 6.3. Начиная с нижнего правого угла схемы, отображается взаимодействие подсистемы РпР и драйверов шины PCI для создания объектов физического и функционального устройств для шины PCI. После этого драйвер шины PCI перечисляет устройства, подключенные к шине PCI, и создает объект физического устройства для адаптера шины SCSI. Драйвер SCSIPort создает объект функционального устройства для адаптера SCSI. Затем драйвер SCSIPort создает объект физического устройства для одного диска, подключенного к системе, а драйвер класса диска создает объект функционального устройства для этого диска.

Диспетчер разделов следит за проходящими пакетами IRP и обеспечивает правильный путь ввода-вывода для завершения обработки пакетов. Как только диспетчер разделов отмечает завершение обработки запроса IRP_MN_ QUERY_DEVICE_RELATIONSHIPS, он незаметно удаляет все данные об обнаруженных устройствах (дисках). В данном случае речь идет об объектах устройств для двух разделов – 0 и 1, которые создаются драйвером класса диска disk. sys. Таким образом, объекты устройств для разделов 0 и 1 никогда не обнаруживаются подсистемой РпР. Именно поэтому объекты для разделов 0 и 1 обозначены цветом, отличным от цвета остальных объектов устройств (см. рис. 6.3).

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

Рис. 6.3. Дерево объектов устройств для устаревшего составного тома на базовом диске

В примере, показанном на рис. 6.3, драйвер FtDisk становится владельцем устройств объектов. После этого диспетчер FtDisk проверяет конфигурацию тома и определяет, что том состоит из двух разделов, которые диспетчер принимает во владение. На этом этапе диспетчер FtDisk создает объект устройства для представления тома (который на рис. 6.3 называетсяТом V01). Затем для тома может быть смонтирована файловая система.

Стоит упомянуть, что в данном случае используется два отдельных стека устройств. Один стек представляет собой логический элемент – том; второй стек содержит физические устройства системы, например шипу PCI, адаптер шины SCSI и дисковый привод. Диспетчер томов выступает в роли моста между этими двумя стеками.

На рис. 6.3 драйвер FtDisk отправляет все распознанные запросы IRP непосредственно драйверу класса диска. Конечно, драйвер FtDisk перед отправкой пакета проводит преобразование смещений относительно тома в смещения относительно диска. Кроме того, запросы управления вводом-выводом, которые не воспринимаются драйвером FtDisk, отправляются разделу О или 1, в зависимости от назначения запроса.

6.2.4 Дерево устройств для томов динамических дисков

Рассмотрим подробнее дерево устройств для томов динамических дисков, которое отличается рядом параметров от дерева устройств для томов на базовых дисках. На рис. 6.4 показано дерево устройств для томов на динамических дисках.

Чтобы не усложнять пример, представим, что рассматриваемый том исключительно программный и находится на динамическом диске. Динамический диск не содержит системного или загрузочного раздела операционной системы, т.е. в записи MBR динамического диска указано, что диск имеет один раздел, занимающий весь свободный объем. Конечно, последний мегабайт жесткого диска содержит базу данных диспетчера томов LDM.

Рис. 6.4. Дерево устройств для тома на динамическом диске

На рис. 6.4 представлены два отдельных дерева объектов, которые читателю уже знакомы: дерево физических объектов (справа), дерево логических объектов (слева) и диспетчер логических дисков (LDM), соединяющий оба дерева. Начиная с нижнего правого угла, на рис. 6.4 представлена пары объект физического устройства-объект функционального устройства для шины PCI. Выше можно заметить пару «объект физического устройства-объект функционального устройства» для шины SCSI. В этом примере к системе подключены два динамических диска. На следующем уровне показана пара «объект физического устройства-объект функционального устройства» для двух физических дисков, установленных в системе. Диспетчер разделов расположен над объектами функциональных устройств, созданными драйвером класса диска.

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

Диспетчер томов LDM перенаправляет ввод-вывод от объекта тома к одному из дисков, который содержит необходимые данные. Обратите внимание, что два объекта разделов – раздел 0 для диска 1 и раздел 0 для диска 2 – никогда не передаются подсистеме РпР, поэтому они не связаны с другими объектами.

 

6.3 Пространство имен устройств

Данное пространство имен развилось за несколько лет существования Windows NT. Для обеспечения обратной совместимости новое пространство имен объединяется со старым пространством с помощью символических ссылок. Кроме того, драйверы режима ядра создают пространство имен в режиме ядра, используя возможности диспетчера объектов. Приложения пользовательского режима воспринимают другие пространства имен, взаимодействующие друг с другом посредством символических ссылок. Иногда разобраться с хитростями пространств имен не так-то просто. В этом разделе делается скромная попытка перечислить наиболее важные для подсистемы хранения имена устройств.

Драйвер класса диска создает объекты устройств для представления каждого физического диска. Эти объекты имеют название \device\harddiskX, где X – число, начинающееся с нуля и увеличивающееся для каждого найденного жесткого диска.

Кроме того, драйвер класса диска создает объект устройства для каждого найденного основного раздела. Драйвер класса диска использует функцию IoReadPartitionTable диспетчера ввода-вывода для поиска всех основных разделов на диске. Такие основные разделы называются \device\harddiskX \partitionY, где X – номер диска, а У – номер основного раздела, расположенного на этом физическом диске. Диспетчер ввода-вывода создает символьную ссылку в формате \??\PhysicalDriveX, где X – число больше нуля, отображаемое на ссылку \device\harddiskX\partitionY.

Диспетчер томов LDM создает объект для каждого поддерживаемого тома. Эти объекты устройств имеют имена в формате \Device\HarddiskVolumes \PhysicalDmVolumes\BlockVolumeX, где X – идентификатор, который назначается тому диспетчером томов. Это устройство режима ядра соотносится с устройством Win32, которое создается диспетчером монтирования и имеет вид \??\Volume [GUID], где GUID – глобально уникальный идентификатор. Диспетчер томов также создает символьную ссылку в формате \Device\HarddiskDmVolumes\ComputerNameDgOWolumeY для каждого тома и соотносит ссылки с определенными устройствами в каталоге PhysicalVolumes При этом значение ComputerName заменяется фактическим именем компьютера, a Y – идентификатором тома.

Для предоставления прямого доступа к тому диспетчер томов LDM создает объект для каждого поддерживаемого тома. Этот объект устройства имеет имя в формате \Device\HarddiskDmVolumes\PhysicalDmVolumes\RawVolumeX.

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

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

 

6.4 Другие файловые системы

Операционная система Windows NT обеспечивает поддержку различных файловых систем. Основной, обладающей полным спектром возможностей файловой системой является NTFS. Компания Microsoft утверждает, что в ныне устаревшую файловую систему FAT новые функции вноситься не будут. Кроме NTFS и FAT (которые рассматриваются далее в главе), операционная система поддерживает и другие файловые системы.

Файловая система CDFS, совместимая со стандартом ISO 9660 и предназначенная для ввода-вывода данных на дисководы для компакт-дисков.

Файловая система UDF (Universal Disk Format), разработанная ассоциацией OSTA. Поддержка UDF была впервые реализована в Windows 2000. Эта файловая система – наследник CDFS, поддерживающий DVD. В Windows 2000 предоставляется поддержка только чтения, а в Windows ХР – как чтения, так и записи данных.

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

6.4.1 Файловая система FAT

Операционная система Windows 2000 поддерживает обновленную версию FAT (File Allocation Table). Следует отметить ряд особенностей FAT.

Существует две версии файловой системы FAT – FAT 16 с 16-разрядными указателями и FAT32 с 32-разрядными указателями.

Файловая система FAT16 поддерживает тома размером дй 4 Гбайт при условии применения кластеров размером 64 Кбайт. Файловая система FAT32 поддерживает разделы размером до 32 Гбайт при условии применения кластеров размером 16 Кбайт.

Корневой каталог может содержать не более 512 записей.

Сжатие и механизмы безопасности не поддерживаются.

 

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

6.5.1 Системные файлы NTFS

Файловая система организует все содержимое диска в виде файлов, включая не только пользовательские файлы, но и файлы, содержащие метаданные, которые относятся к файловой системе. В этом разделе рассматриваются файлы, которые 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.

6.5.2 Логические и виртуальные номера кластеров NTFS

Файловая система 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-й кластер определенного файла.

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

6.5.3 Структура записи MFT в файловой системе NTFS

Как уже отмечалось, каждый файл и каталог в 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 с именем файла в виде относительного или абсолютного пути. Указав имя файла и имя потока через двоеточие, можно открыть другой поток данных, например \directoryl\Filel: DataStream2. Файловая система NTFS хранит эту информацию как еще один атрибут в MFT, а данные второго потока хранит в виде другого атрибута.

6.5.4 Каталоги NTFS

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

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

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

6.5.5 Журнал восстановления NTFS

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

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

6.5.6 Безопасность NTFS

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

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

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

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

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

6.5.7 Разреженные файлы NTFS

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

Разреженные и сжатые файлы представляют собой две совершенно разные независимые структуры, предназначенные для сокращения объема используемого дискового пространства. Файл может быть сжатым, но неразреженным и наоборот. Сжатие рассматривается в разделе 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.

6.5.8 Сжатые файлы NTFS

Файловая система 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.

6.5.9 Пользовательские квоты дискового пространства

В 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, для последующей обработки.

6.5.10 Базовые наборы атрибутов NTFS

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

6.5.11 Владение файлом

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

6.5.12 Расширенная проверка списков управления доступом

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

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

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

6.5.13 Журнал изменений, журнал USN и файл журнала изменений

Начиная с 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.

6.5.14 Переименование потоков NTFS

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

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

6.5.15 Идентификаторы объектов и отслеживание ссылок

Операционная система 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 функции управления файловой системой.

6.5.16 Улучшения утилиты CHKDSK

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

6.5.17 Индексация содержимого файловой системы

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

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

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

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

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

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

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

6.5.18 Тома NTFS, предназначенные только для чтения

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

6.5.19 Фрагментация и дефрагментация NTFS

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

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

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

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

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

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

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

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

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

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

Фрагментация каталогов является еще одной проблемой. Некоторые каталоги, например с файлами приложений, редко увеличиваются или уменьшаются в размерах; другие каталоги, например Мои документы или 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).

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

6.5.20 Шифрованная файловая система

В 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-узле по адресу: . 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

6.5.21 Закрепленные ссылки NTFS

Файловая система 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.

6.5.22 Точки повторной обработки

Это относительно новая функция 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. Таким образом, приложение может быстро индексировать все эти точки.

6.5.22.1 Точки монтирования томов

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

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

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

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

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

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

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

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

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

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

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

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

6.5.22.3 Хранилище SIS

В 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 с возможностью 'восстановления всех файлов ссылок и данных.

6.5.22.4 Технология HSM

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

 

6.6 Файловые системы для сетей хранения данных

Сети хранения данных позволяют администраторам сформировать пул ресурсов хранения сосуществующих с группой серверов, когда отдельные ресурсы подсистемы хранения можно назначать разным серверам. Для SAN необходимо, чтобы в любой момент времени только определенный сервер мог получить доступ к определенным ресурсам подсистемы хранения. Сети хранения данных предоставляют эффективный способ переназначения ресурсов подсистемы хранения данных между серверами. Чтобы лучше понять этот механизм, обратитесь к рис. 6.14.

Рис. 6.14. Использование сети хранения данных с локальной файловой системой

На рис. 6.14 демонстрируется типичная трехуровневая архитектура сети хранения данных. На верхнем уровне находятся клиенты, получающие доступ к серверам по локальной сети. Серверы подключены к коммутатору Fibre Channel. Кроме того, к коммутатору подключено несколько дисков. Диски подсистемы хранения можно рассматривать как пул дисков, состоящий из дисков D1-D4. На рис. 6.14 показан сервер 1 и диски D1 и D3, закрашенные другим цветом, так как сервер 1 получает эксклюзивный доступ к дискам D1 и D3. Сервер 2 получает эксклюзивный доступ к дискам D2 и D4.

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

Для одновременного совместного доступа к ресурсу подсистемы хранения (например, к тому) несколькими серверами необходима поддержка рас-

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

Сервер NAS может легко превратиться в проблемный элемент системы хранения данных. Такие сетевые файловые системы, как CIFS и NFS (см. главу 3), предоставляют совместный доступ на уровне файлов. При этом поддерживаются клиенты, которые обращаются к серверу по сетевому протоколу, например TCP/IP. Файловые системы сетей хранения данных предоставляют совместный доступ к устройствам хранения на уровне блоков. При этом поддерживаются клиенты, использующие протокол уровня блоков, например SCSI. При использовании файловых систем SAN каждый сервер использует то, что воспринимается им в качестве файловой системы на локальном диске. Но в реальности в рамках подобной «иллюзии» работает несколько серверов. При этом файловая система сети хранения данных, выполняющаяся на каждом из серверов, корректно поддерживает состояние файловой системы на томе, на котором одновременно работает несколько серверов.

Чтобы понять такую архитектуру, следует обратиться к диаграмме. На рис. 6.15 демонстрируется два сценария работы. В левой части диаграммы представлен диск NAS, к которому несколько серверов получают доступ с помощью сетевой файловой системы. В правой части диаграммы показано несколько серверов, получающих доступ к единственному диску с помощью файловой системы сети хранения данных. В первом случае каждый сервер использует сетевую файловую систему (например, SMB или NFS) для отправки запросов на сервер устройства NAS. Таким образом, устройство NAS потенциально является единственной точкой отказа, а также проблемным элементом в контексте производительности всей системы. При использовании сетевой файловой системы единственной точки отказа или проблемного элемента производительности просто не существует. Диск подсистемы хранения данных может предоставляться клиентам через схему балансировки нагрузки. Если один из серверов откажет в работе, данные диска можно будет получить, обратившись к другому диску. Конечно, при этом схема усложняется и становится дороже за счет стоимости файловой системы SAN.

Рис. 6.15. Сценарии использования файловых систем NAS и SAN

6.6.1 Преимущества файловых систем SAN

Ниже перечислены преимущества файловых систем SAX.

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

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

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

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

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

Приложения могут выбирать тип хранилища, наиболее подходящий их требованиям, например RAID О, RAID 1 или RAID 5.

Масштабируемость SAN можно сравнить с компьютерным эквивалентом конструктора LEGO. Для получения дополнительной мощности достаточно добавить сервер и настроить его на доступ к существующему диску.

6.6.2 Проблемы использования файловых систем SAN

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

Обратите внимание: сложность достижения баланса между параллельностью и сериализацией присуща и другим файловым системам, не связанным с сетями хранения данных, например к NTFS. Различие заключается в том, что механизмы обеспечения корректной сериализации имеют более простую структуру и предоставляются операционными системами. Например, механизмы синхронизации, предоставленные Windows, в частности spin- блокировка и семафоры, отлично подходят для использования в файловых системах, не связанных с SAN, например в NTFS.

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

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

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

Возможны проблемы при произвольном или непроизвольном изменении конфигурации. Например, в сети (TCP/IP или сети хранения данных) меняется топология, что приводит к прекращению доступа к некоторым узлам.

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

Программные массивы RAID вообще не могут быть использованы или требуют сложной схемы реализации. Применению программных массивов RAID соответствует два уровня связывания. На первом уровне файловая система соотносит ввод-вывод с уровнем тома или раздела. На следующем уровне компонент программного массива RAID (диспетчер логических дисков в Windows 2000) соотносит ввод-вывод на уровне тома с вводом-выводом на уровне блоков физических дисков. Более того, для предотвращения повреждения данных необходимы методы, задействующие два уровня блокировки сетей хранения данных. Первая блокировка выполняется на уровне файловой системы, что обеспечивает сериализацию между различными системами под управлением Windows, пытающимися записывать совмещающиеся данные в один и тот же файл. Кроме того, поскольку компоненты программного массива RAID попытаются обновить данные о четности файла, диспетчер логических дисков или его аналоги, работающие на разных компьютерах, должны обеспечить механизм взаимоисключающей блокировки сети хранения данных.

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

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

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

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

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

Файловые системы в гетерогенных системах могут иметь различные размеры; например, существуют 32- и 64-разрядные файловые системы. Все структуры требуют обеспечения корректного взаимодействия. В практической реализации структуры данных приходится преобразовывать в обоих направлениях, не забывая о необходимости дополнения до размерности в 4, 8, 16, 32 и 64 бит.

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

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

Асимметричный подход, при котором определенный узел выступает в роли сервера метаданных и центральной точки синхронизации. Сервер метаданных отвечает за управление всеми метаданными файловой системы (например, данные о выделении дисковых кластеров). Другие серверы с файловой системой SAN обращаются к этому серверу для получения метаданных, например информации о выделении дисковых кластеров, а также идентификатора диска, идентификатора LUN и т.д. После получения метаданных серверы могут выполнять ввод-вы- вод непосредственно по сети хранения данных. Некоторые поставщики, например ADIC и ЕМС, предоставляют коммерческие продукты для платформы Windows NT, основанные на асимметричной технологии.

Рис. 6.16. Файловая система SAN с сервером метаданных

Асимметричный подход к проектированию файловой системы SAN продемонстрирован на рис. 6.16.

Клиент подключается к серверу и запрашивает данные с помощью одного из протоколов, например CIFS (см. главу 3).

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

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

6.6.3 Коммерчески доступные файловые системы SAN

Некоторые поставщики реализовали файловые системы SAN для платформы Windows NT на базе асимметричной технологии. В качестве примеров можно привести линию продуктов Celerra HighRoad от компании ЕМС, продукт SANergy от компании Tivoli и продукт StorNext (ранее известный как CentraVision) от компании ADIC. Все эти системы используют сервер Windows для реализации сервера метаданных и поддержки доступа к серверу метаданных со стороны вторичных серверов Windows. Некоторые системы поддерживают изолированный сервер метаданных, а некоторые – нет. Кроме того, ряд систем поддерживают другие серверы (например, Novell, UNIX или Solaris), которые могут получать доступ к серверу метаданных.

Рис. 6.17. Стек ввода-вывода файловой системы SAN в Windows NT

Рассмотрим более подробно реализацию описанных функций в контексте стека ввода-вывода Windows NT.

На рис. 6.17 показан стек сетевого ввода-вывода Windows NT и локального хранилища (на основе моделей драйверов Storport и SCSIPort). Драйвер фильтрации файловой системы SAN (закрашенный на рисунке другим цветом) находится уровнем выше сетевой файловой системы в целом и Мини- перенаправителя CIFS в частности. Драйвер фильтрации перехватывает запросы на открытие, закрытие, создание и удаление файлов и позволяет им перемещаться по пути стандартного стека сетевой файловой системы. Перехват запросов используется для регистрации процедуры завершения. Для всех успешно открытых файлов драйвер фильтрации получает информацию о точной дорожке, секторе и блоке диска, в которых расположен файл.

Такая процедура выполняется для всех больших файлов. Некоторые системы отказываются от выполнения этой процедуры для небольших фай-

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

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

 

6.7 Сложности практической реализации

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

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

Отметим, что на данный момент ни один поставщик не разрабатывает и не продает файловую систему для платформы Windows NT (кроме, естественно, самой Microsoft). Но в будущем ситуация может измениться.

 

6.8 Резюме

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

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

Файловые системы SAN предоставляют определенные преимущества при работе в сетях хранения данных. Некоторые поставщики реализовали файловые системы сетей хранения данных в среде Windows NT, применив подход с централизованным сервером метаданных.