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

В файловой системе HPFS, используемой в OS/2 и Windows NT, каждая запись в каталоге содержит имя файла и указатель на fnode (файловую запись). Каталоги в этой ФС организованы в виде В-деревьев и отсортированы по именам файлов.

Файловая запись занимает один блок на диске и содержит список так называемых extent («расширений») – (у этого термина нет приемлемого русского аналога. В переводах документации по OS/360 (OC EC) так и писали: экстент.). каждый экстент описывает непрерывную последовательность дисковых блоков, выделенных файлу. Он задает начальный блок такой последовательности и ее длину. Вместо списка свободных блоков используется битовая карта диска, в которой каждому блоку соответствует один бит: занят/свободен. Нужно отметить, что идея экстентов далеко не нова: аналогичная структура используется в некоторых версиях Unix с начала 80-х годов, а истоки этой идеи теряются в глубине 60-х.

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

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

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

Экстенты открытых файлов и карта свободных блоков во время работы размещаются в ОЗУ поэтому производительность такой ФС в большинстве ситуации намного (в 1,5-2 раза и больше) выше, чем у FAT с тем же объемом КЭШа, при вполне приемлемых потребностях в памяти и размере кластера 512 байт.

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

ФС Unix. Наиболее интересна структура файловых систем в ОС семейства Unix. В этих ФС каталог не содержит почти никакой информации о файле. Там хранится только имя файла и номер его инода (i-node – по-видимому, сокращение от index node: индексная запись). Иноды всех файлов в данной ФС собраны в таблицу, которая так и называется: таблица инодов. В ранних версиях Unix таблица инодов занимала фиксированное пространство в начале устройства; в современных файловых системах эта таблица разбита на участки, распределенные по диску.

Например, в файловой системе BSD Unix FFS (Fast File System –быстрая файловая система), которая в Unix SVR4 называется просто UFS (Unix File System), диск разбит на группы цилиндров. Каждая группа цилиндров. Каждая группа цилиндров содержит копию суперблока, битовую карту свободных блоков для данного участка и таблицу инодов для файлов, расположенных в пределах этого участка(рис.12). такая распределенная структура имеет два преимущества.

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

Инод хранит информацию о самом файле и его размещении на диске (рис.13).

• Тип файла. Исследуя это поле, можно понять, является данный объект файлом данных или специальным файлом. В этом же поле закодированы права доступа к файлу.
• Идентификаторы владельца файла и группы. Вместе с правами доступа эти два идентификатора образуют список контроля доступа файла.
• Время: создания файла; последней модификации файла; последнего доступа к файлу.

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

Рис. 11.Каталог и файловая запись в HPFS.

Рис.12

Рис. 13.Каталоги и иноды файловых систем семейства Unix.

Структура, описывающая физическое размещение файла на диске, недоступна пользовательским программам. Собственно, формат этой структуры может быть очень разнообразен. Например, в файловой системе Veritas это список элементов, похожий на HPFS; в файловых системах s5, Xenix и FFS это массив из 13 чисел, задающих номера физических блоков файла. Если файл в s5 содержит более десяти блоков (т.е. его длина больше 5 Кбайт), то предпоследние три указателя обозначают не блоки данных, а так называемые косвенные блоки (indirection blocks), в которых хранятся указатели на следующие блоки данных и, возможно, на следующие косвенные блоки.

Наиболее интересная особенность ФС семейства Unix состоит в том, инод не содержит имени файла. С другой стороны, он содержит счетчик связей (link) – ссылок на этот файл из каталогов. Таким образом, на один и тот же инод можно ссылаться из различных каталогов или из одного каталога под разными именами (рис.14). Иными словами, один и тот же файл в этих ФС может иметь несколько различных имен. Именно это и имелось в виду, когда говорилось, что структура каталогов в ОС Unix не обязана быть деревом.

Это свойство предоставляет неоценимые возможности для организации иерархии каталогов, но имеет и некоторые оборотные стороны:

1. создание нескольких связей для каталога потенциально опасно – оно может привести к возникновению кольца, в котором каталог является своим собственным подкаталогом. Отслеживать такую ситуацию сложно, поэтому разработчики ОС Unix запретили создавать дополнительные имена каталогов.
2. удаление файла превращается в проблему: чтобы удалить файл, нужно проследить все его связи. Поэтому UNIX не имеет средств для удаления файла, а обладает только системным вызовом unlink – удалить связь. Когда у файла не остается связей, он действительно удаляется. Этот подход вполне разумен, но также имеет неожиданную оборотную сторону: поскольку теперь стирание файла – это операция не над файлом, а над каталогом, то для удаления файла не нужно иметь никаких прав доступа к нему. Достаточно иметь право записи в каталог.

На практике, механизм защиты от стирания отдельных файлов предусмотрен – при установке в атрибутах каталога так называемого sticky bit(“липкий бит”), система запрещает стирать файлы, для которых вы не имеете права записи, но этот механизм не лишен недостатков.

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

Рис. 14. Жесткие связи вUnix.

Последнее обстоятельство резко уменьшает полезность жесткость связей для организации иерархии каталогов. Эта проблема была осознана еще в 70-е годы, и программисты из группы BSD придумали интересное новое понятие – символическую связь (symbolic link) или symlink.

Символическая связь представляет собой специальный файл. Вместо блоков данных инод такого файла содержит текстовую строку – имя того файла, с которым создана связь (рис.15). это может быть файл из другой файловой системы, в том числе и из такой, которая сама по себе не поддерживает ни жестких дисков, ни символических связей, например, FAT, HPFS или файловый сервер Nowell Netware. Такого файла может и вообще не существовать , например, потому, что его уже удалили, или потому, что файловая система, в которой он находится, не смонтирована, или просто потому, что имя было задано неправильно. Тогда попытки открыть символическую связь будут завершаться неудачей с кодом ошибки «файла не существует». Естественным недостатком символических связей является их относительно низкая «дуракоустойчивость» (fool-tolerance): глупый пользователь может не распознавать ситуации, когда символическая связь указывает в никуда. Зато они обеспечивают полную свободу в размещении и именовании файлов.

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

Рис. 15.Символическая связь.

ФС NTFS подробно описана выше, в разделе «Физическая организация ФС».

Устойчивость ФС