Недостатки и ограничения

Файловая система s5fs привлекательна благодаря своей простоте. Обратной стороной медали является низкая надежность (????????????) и производительность (?????????????).

Массив inode имеет фиксированный размер, задаваемый при создании файловой системы. Этот размер накладывает ограничение на максимальное число файлов, которые могут существовать в файловой системе.

Ограничения: длина имени файла (14 символов) и общее максимальное число inode (65535).

Файловая система BSD UNIX -Berkeley Fast File System (FFS).

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

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

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

В суперблоке не хранятся данные о свободном пространстве файловой системы, такие как массив свободных блоков и inode.

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

данные суперблока дублируются для повышения надежности.

Организация файловой системы предусматривает логическое деление дискового раздела на одну или несколько групп цилиндров (cylinder group). Группа цилиндров представляет собой несколько последовательных дисковых цилиндров.

Каждая группа цилиндров содержит

• управляющую информацию, включающую резервную копию суперблока,

• массив inode,

• о свободных блоках

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

(рис. 4.4).

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

обычно на каждые 2 Кбайт блоков хранения данных создается один inode.

Т.К. размеры группы цилиндров и массива inode фиксированы, в файловой системе BSD UNIX присутствуют ограничения, аналогичные s5fs.

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

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

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

Управляющая информация располагается с различным смещением от начала группы цилиндров.

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

Файловая система FFS поддерживает размер блока до 64 Кбайт.

Типичная файловая система UNIX состоит из значительного числа файлов небольшого размера. Это приводит к тому, что частично занятые блоки используются неэффективно, что может привести к потере до 60% полезной емкости диска.

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

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

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

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

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

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

В файлов системе s5fs используются весьма примитивные правила размещения.

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

В отличие от s5fs, файловая система FFS при размещении блоков использует стратегию, направленную на увеличение производительности:

• Файл, по возможности, размещается в блоках хранения данных, принадлежащих одной группе цилиндров, где расположены его метаданные.

• Все файлы каталога по возможности размещаются в одной группе цилиндров.

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

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

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

эти параметры файловой системы FSS начинают значительно ухудшаться по мере уменьшения сво­бодного места (д.б. более 10% свободного места)

Каталоги

Структура каталога FFS изменена: для поддержки длинных имен файлов (до 255 символов).

Запись каталога FFS представлена структурой, имеющей следующие поля:

d_ino	Номер inode (индекс в массив ilist)
d_reclen	Длина записи
d_namlen	Длина имени файла
d_name[]	Имя файла

Имя файла имеет переменную длину, дополненную нулями до 4-байтной границы. При удалении имени файла принадлежавшая ему запись присоединяется к предыдущей, и значение поля d_reclen увеличивается на соответствующую величину. Удаление первой записи выражается в присвоении нулевого значения полю d_ino. Структура каталога файловой системы FFS приведена на рис. 4.6.

Архитектура виртуальной файловой системы

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

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

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

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

Виртуальные индексные дескрипторы

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

виртуальная файловая система основана на представлении метаданных файла в виде, сходном с традиционной семантикой UNIX. Интерфейсом работы с файлами является vnode (от virtual node — виртуальный индексный дескриптор).

разработан в 1984 году фирмой Sun Microsystems для обеспечения требуемой унификации работы с файловыми системами различных типов, в частности, с NFS и ufs (FFS). Сегодня виртуальная файловая система является стандартом в SVR4, хотя ряд других версий UNIX также реализуют подобную архитектуру (например, независимая файловая система SCO UNIX).

Метаданные всех активных файлов (файлов, на которые ссылаются один или более процессов) представлены в памяти в виде in-core mode, в качестве которых в виртуальной файловой системе выступают vnode.

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

Основные поля vnode приведены в табл. 4.1.

Каждый vnode содержит число ссылок v_count, которое увеличивается при открытии процессом файла и уменьшается при его закрытии. Когда число ссылок становится равным нулю, вызывается операция vn_inactive(), которая сообщает реальной файловой системе, что на vnode никто больше не ссылается. После этого файловая система может освободить vnode (и, например, соответствующий ему inode) или поместить его в кэш для дальнейшего использования.

Поле v_vfsp указывает на файловую систему (структуру vfs, о которой мы поговорим в следующем разделе), в которой расположен файл, адресованный данным vnode. Если vnode является точкой монтирования, то поле v_vfsmountedhere указывает на подключенную файловую систему, “перекрывающую” данный vnode.

Поле v_data указывает на данные, относящиеся к конкретной реализации реальной файловой системы. Например, для дисковой файловой системы ufs, v_data указывает на запись в таблице in-core inode.

Набор операций над vnode указан полем v_op (представляет собой виртуальные методы класса vnode.)

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

Взаимосвязь между независимыми дескрипторами (vnode) и зависимыми от реализации метаданными файла показана на рис. 4.8.

Монтирование файловой системы

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

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

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

Поле vfs_data содержит указатель на данные реальной файловой системы. Например, для дисковой файловой системы s5fs, это поле указывает на суперблок, размещенный в памяти.

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

Для инициализации и монтирования реальной файловой системы UNIX хранит коммутатор файловых систем (File System Switch), адресующий процедурный интерфейс для каждого типа файловой системы, поддерживаемой ядром. UNIX System V для этого использует глобальную таблицн, каждый элемент которой соответствует определенному типу реальной файловой системы, например s5fs, ufs или nfs. Элемент этой таблицы vfssw имеет поля, указанные в табл. 4.5.

Взаимодействие структур виртуальной файловой системы показано на рис. 4.9.

Монтирование файловой системы производится системным вызовом mount(2). В качестве аргументов передаются тип монтируемой файловой системы, имя каталога, к которому подключается файловая система (точка монтирования), флаги (например, доступ к файловой системе только для чтения) и дополнительные данные, конкретный вид и содержимое которых зависят от реализации реальной файловой системы. При этом производится поиск vnode, соответствующего файлу – точке монтирования (операция lookup() или namei() трансляции имени), и проверяется, что файл является каталогом и не используется в настоящее время для монтирования других файловых систем.

Затем происходит поиск элемента коммутатора файловых систем vfssw[], соответствующего типу монтируемой файловой системы. Если такой элемент найден, вызывается операция инициализации, адресованная полем vsw_init(). При этом выполняется размещение специфических для данного типа файловой системы данных, после чего ядро размещает структуру vfs и помещает ее в связанный список подключенных файловых систем, как это показано на рис. 4.11. Поле vfs_vnodecovered указывает на vnode точки монтирования. Это поле устанавливается нулевым для корневой (root) файловой системы, элемент vfs которой всегда расположен первым в списке подключенных файловых систем. Поле vfs_op адресует вектор операций, определенный для данного типа файловой системы. Наконец, указатель на данный элемент vfs сохраняется в поле v_vfsmountedhere виртуального индексного дескриптора каталога – точки монтирования.

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

• проверку соответствующих прав на выполнение монтирования;

• размещение и инициализацию специфических для файловой системы данного типа данных, сохранение адреса этих данных в поле vfs_data элемента vfs;

• размещение vnode для корневого каталога подключаемой файловой системы, доступ к которому осуществляется с помощью операции vfs_root().

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

Определение корневого vnode для подключенной файловой системы производится с помощью операции vfs_root(). Заметим, что в некоторых реализациях независимой файловой системы (например, в SCO UNIX, хотя там используется другая терминология) одно из полей записи таблицы монтирования явно указывало на корневой vnode. Подход, предложеный фирмой Sun Microsystems, позволяет не хранить корневой vnode постоянно, размещая его только при необходимости работы с файловой системой. Это минимизирует ресурсы, занимаемые подключенными файловыми сис­темами, которые продолжительное время не используются.

На рис. 4.10 приведен вид логического файлового дерева до и после монтирования файловой системы А к каталогу /usr/local. На рис. 4.11 приведен вид виртуальной файловой системы после этой операции монтирования.

Исследовать описанные структуры данных можно с помощью утилиты crash(lM). Для этого применяются команды vfs и vnode, отображающие содержимое соответствующих структур данных. Приведем пример такого исследования файлового дерева операционной системы Solaris2.5:

Мы распечатали список подключенных файловых систем (коман mount(lM)) и элементы vfs таблицы монтирования. Рассмотрим подробнее vnode точки монтирования файловой системы раздела /dev/dsk/c0t0d0s.

Удостоверимся, что поле v_vfsmountedhere (VFSMNTED) адресует элемент vfs подключенной файловой системы, а поле v_fsp (vfsp) указывает на элемент корневой файловой системы.

Наконец, посмотрим на содержимое inode файловой системы ufs, адресованного полем v_data (VDATA) виртуального индексного дескриптора.

Полученная информация показывает, что запись таблицы inode ufs адресует дисковый индексный дескриптор с номером 7552 (INUMB). Для того чтобы узнать имя файла, используем команду ncheck(1M):

> !ncheck –i 7552

/dev/dsk/c0t3d0s0:

7552 /usr/local