Файл: Учебнометодическое пособие Томск 2016 2 удк 004. 451(075. 8) Ббк 32. 973. 2018. 2я73 к 754 Рецензенты.pdf

201
Структура первой из них аналогична записи каталога в fat12и в fat16, а в последующих записях содержится длинное (до 255 байтов) простое имя файла.
Таким образом, один и тот же файл, принадлежащий программной части fat32
, может обрабатываться как программной частью fat12 или fat16
(используется короткое имя файла), так и программной частью fat32 (исполь- зуется длинное имя файла).
Обратим внимание, что среди перечисленных полей элемента каталога нет перечня прав доступа к дочернему файлу со стороны различных типов пользователей. Это является следствием того, что операционные системы
MS-DOS и Windows, для которых fat «родная», являются однопользователь- скими. Поэтому, выполняя запросы виртуальной ФС, программная часть fat возвращает ей для каждого файла одинаковый набор прав доступа, например rwxrwx --- (см. п. 4.2).
7.2.4 Управляющие структуры данных
Информационная часть реальной ФС включает физические файлы, раз- мещенные на носителе ВП или в его разделе, а также управляющие структуры данных, находящиеся на этом же носителе (разделе носителя). Реальные ФС, разработанные для UNIX, содержат управляющие структуры данных:
1) суперблок – дескриптор информационной части реальной ФС. Этот блок управления содержит информацию, необходимую для управле- ния всей информационной частью реальной ФС;
2) массив inode. Каждый inode представляет собой дескриптор како- го-то одного физического файла, принадлежащего данной информа- ционной части реальной ФС. При открытии файла inode считывает- ся с носителя в ОП и становится элементом таблицы активных inode.
Система s5fs. Каждая информационная часть этой реальной ФС имеет всего один суперблок, который находится в начале раздела и содержит поля:
1) тип реальной ФС (s5fs);
2) размер информационной части реальной ФС в блоках;
3) размер массива inode;
4) число свободных блоков;
5) число свободных inode;
6) размер блока (512, 1024, 2048, …);

202 7) список номеров свободных inode;
8) список номеров свободных блоков.
Размер списка номеров свободных inode во много раз меньше предель- ного числа файлов, которое дляs5fsравно 65 535. Поэтому при исчерпании этого списка программная часть реальной ФС просматривает массивinode с целью поиска его свободных элементов (каждый свободный inode имеет спе- циальную отметку в своем первом поле). Найденные номера помещаются в список номеров свободных inode.
Что касается списка номеров свободных блоков, то его приходится хра- нить целиком. Первой причиной этого является то, что блоки не имеют специ- альных отметок об их занятости. Другой причиной являются большие затраты времени на считывание блоков для их просмотра из-за их значительных разме- ров. Для того чтобы не ограничивать размеры списка номеров свободных бло- ков, поступают следующим образом. Во-первых, сам суперблок содержит лишь начальную часть этого списка. Первый элемент этой части списка, в отличие от других элементов, содержит не номер свободного блока, а номер блока, со- держащего продолжение списка. Если требуется, то первый элемент этого бло- ка с продолжением также содержит номер блока, используемого для продолже- ния списка, и т. д.
Дескриптор физического файла inode в реальной ФС s5fsсодержит поля:
1) тип файла, права доступа;
2) число ссылок на файл, совпадающее с числом его имен в логической файловой структуре системы;
3) имена пользователя-владельца и пользователя-группы;
4) размер файла в байтах;
5) время последнего доступа к файлу;
6) время последней модификации;
7) время последней модификации inode (кроме модификации полей 5 и 6);
8) массив номеров блоков, занимаемых данными файла.
Последнее поле содержит массив из 13 элементов, первые десять из кото- рых содержат номера первых десяти блоков файла. Последние три элемента ис- пользуются соответственно для косвенной, двойной косвенной и тройной кос- венной адресации блоков файла. Косвенная адресация заключается в том, что

203 11-й элемент массива содержит номер того блока раздела, который содержит номера блоков занимаемых файлов. Двойная косвенная адресация реализуется за счет того, что 12-й элемент массива содержит номер блока, используемого для хранения номеров блоков, косвенно адресующих блоки файла. Тройная косвенная адресация заключается в том, что 13-й элемент массива содержит номер блока, в котором находятся номера блоков, используемых для двойной косвенной адресации блоков файла.
Система ffs. В этой реальной ФС каждая информационная часть имеет с целью повышения надежности не один экземпляр суперблока, а несколько – по одному суперблоку на каждую группу цилиндров. Для того чтобы не вно- сить в каждую копию суперблока текущие изменения (во время этой операции может произойти сбой в системе), суперблок содержит лишь постоянную ин- формацию о разделе. Поэтому суперблок ffs не имеет таких полей, присущих суперблоку s5fs, как «число свободных блоков» или «число свободных inode
».
Вслед за суперблоком каждая группа цилиндров содержит битовую кар- ту блоков и список свободных inode, расположенных в этой группе цилин- дров. Список свободных inode содержит перечень номеров свободных эле- ментов в массиве inode. Размер данного массива позволяет иметь один inode на каждые 2 Кбайта дисковой памяти, принадлежащей данной группе цилин- дров. Битовая карта блоков – последовательность битов, длина которой (в би- тах) определяется общим числом фрагметов блоков, имеющихся в данной группе цилиндров. При этом каждому фрагменту блока соответствует один бит в данной битовой карте (1 – фрагмент занят, 0 – свободен). Подобное распре- деление управляющей информации между группами цилиндров не только по- вышает производительность реальной ФС, но и существенно улучшает ее надежность, так как порча такой информации в одной группе цилиндров не влияет на доступ к данным в других группах цилиндров.
Система fat.Суперблок (в MS-DOS и Windows этот термин не исполь- зуется) этой реальной ФС находится в начале самого первого сектора раздела.
Перечислим лишь его первые поля:
1) имя изготовителя и версия (8 байт);
2) длина сектора в байтах (2 байта);
3) длина блока (кластера) в секторах (1 байт);
4) число копий таблицы fat.

204
В системе fat массив inode не используется, так как дескрипторы файлов находятся в каталогах. Следствием этого является ненужность списка свободных inode. Отсутствует также список свободных блоков раздела.
Функции этого списка, а также функцию учета блоков, выделенных каждому файлу, выполняет таблица fat(file allocation table), название которой исполь- зуется в качестве названия всей ФС. Таблица fat имеет столько 12-, 16- или
32-битных элементов, сколько блоков раздела могут распределяться между файлами. Иными словами, fat представляет собой уменьшенную модель рас- пределяемой части раздела диска. Ее наличие позволяет размещать файл в раз- рывной области ВП. Для этого каждому файлу ставится в соответствие вспомо- гательный линейный связанный список, построенный из элементов таблицы fat.
Вспомним, что одно из полей записи каталога, описывающей файл, со- держит номер его начального блока и, следовательно, номер соответствующего элемента в таблице fat. Содержимым этого элемента является номер следую- щего элемента связанного списка, который совпадает с номером следующего блока файла. Если элемент fat-таблицы соответствует последнему блоку фай- ла, то он содержит специальное число (FFFh,FFFFh или FFFFFFFFh).
Если элемент fat-таблицы соответствует свободному блоку раздела, то он также содержит специальное число (000h,0000h или 00000000h). Это число используется программной частью системы fat для определения номера блока, который может быть распределен файлу. Для повышения надежности в разделе диска обычно содержится не один, а два экземпляра таблицы fat.
7.3 Объединение реальных файловых систем
Огромное дерево логической файловой структуры системы состоит из фрагментов, физически реализованных на разных устройствах ВП или раз- ных разделах этих устройств. Каждый такой фрагмент имеет древовидную ло- гическую структуру и реализован в виде отдельной информационной части ре- альной ФС. Первоначально файловая структура системы включает лишь корневую реальную ФС (информационную часть), расположенную на систем- ном устройстве ВП, к которой постепенно подсоединяются другие информаци- онные части реальных ФС.

205
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Операция подсоединения одной информационной части ре-
альной ФС к файловой структуре системы называется монтиро-
ванием.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Например, пусть требуется выполнить подсоединение реальной ФС, рас- положенной в разделе диска с именем /dev/rz0b (это имя специального фай- ла раздела), к корневой реальной ФС, расположенной в разделе /dev/rz0a
(рис. 7.4). Для выполнения такого монтирования, во-первых, требуется выбрать в корневой ФС точку монтирования – каталог, к которому будет непосред- ственно подсоединена монтируемая ФС. Обязательным требованием к такому каталогу является его неиспользуемость в качестве точки монтирования для другой ФС. Кроме того, желательно, чтобы этот каталог был пуст. В примере в качестве точки монтирования используется каталог/home/vlad/prog.
Для того чтобы виртуальная ФС выполнила монтирование, она должна быть инициирована с помощью системного вызова:
МОНТИРОВАТЬ (t, I
u
, I
k
||)
, (на Си – mount), где t – тип монтируемой реальной ФС;
I
u
– имя-путь специального файла, соответствующего устройству или раз- делу устройства, на котором расположена монтируемая информацион- ная часть реальной ФС;
I
k
– имя-путь того каталога, который является точкой монтирования.
Первичным источником данного системного вызова является системная обрабатывающая программа mount, запускаемая суперпользователем из ко- мандной строки UNIX и имеющая те же входные параметры, что и системный вызов.
Что касается выполнения системного вызова МОНТИРОВАТЬ, то вирту- альная ФС начинает с того, что находит vnode, соответствующий тому катало- гу «старой» реальной ФС, который выбран в качестве точки монтирования. Да- лее находится тот элемент коммутатора файловых систем, который соответствует заданному типу tреальной ФС.

206
Рис. 7.4  Пример монтирования реальной файловой системы
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

207 2) адрес процедуры инициализации реальной ФС;
3) указатель на вектор операций реальной ФС.
Используя поле 2 найденного элемента коммутатора, виртуальная ФС вы- зывает процедуру инициализации реальной ФС. Эта процедура, во-первых, вы- полняет считывание в ОП суперблока монтируемой информационной части ре- альной ФС; во-вторых, добавляет новый элемент в список монтирования – односвязанный список, элементами которого являются дескрипторы смонтиро- ванных информационных частей реальных ФС. Элемент этого списка содержит поля:
1) указатель на следующий элемент в списке монтирования;
2) указатель на вектор операций реальной ФС. Это – копия соответству- ющего поля элемента коммутатора файловых систем;
3) номер vnodeтого каталога, который является точкой монтирования;
4) размер блока монтируемой системы;
5) указатель на суперблок смонтированной реальной ФС.
Таким образом, в отличие от коммутатора файловых систем, элементы которого используются для доступа к программным частям реальных ФС, эле- менты списка монтирования используются для доступа к информационным ча- стям этих ФС. Напомним, что в системе может быть только одна программная часть реальной ФС, но может существовать любое число ее информационных частей. Первым элементом списка монтирования всегда является корневая ре- альная ФС.
После того как в список монтирования добавлен новый элемент, указа- тель на этот элемент помещается в одно из полей того vnode, который соот- ветствует каталогу, являющемуся точкой монтирования. Кроме того, создается новый vnode для корневого элемента монтируемой реальной ФС.
Интересно отметить, что в результате монтирования происходит логиче- ское слияние двух каталогов, один из которых является точкой монтирования, а второй есть корень монтируемой ФС. Подобное слияние происходит лишь с точки зрения пользователя (на логической файловой структуре системы), так как каждому каталогу по-прежнему соответствует своя физическая реали- зация в своем разделе диска, а также свой отдельный vnode. Данное свойство влияет, в частности, на выполнение трансляции имен файлов. Если при транс- ляции очередного имени файла реальная ФС (программная часть) обнаружит, что достигнута точка монтирования, то она возвратит в виртуальную ФС не си- стемное имя искомого файла, а указатель на подключенную ФС в списке мон-

208 тирования. Далее виртуальная ФС должна инициировать одну из процедур этой
ФС с целью продолжения трансляции имени файла в его системное имя.
Существенные отличия имеет операция монтирования сетевой операци- онной системы nfs, упрощенная схема выполнения которой рассматривается далее. Во-первых, заметим, что эта реальная ФС является примером распреде- ленной программы, включающей одну или несколько серверных частей и одну или несколько клиентских частей. При этом серверные части nfs находятся в узлах-серверах. Любой узел-сервер имеет один или несколько каталогов, каж- дый из которых является корнем поддерева файловой структуры, «экспортиру- емого» в узлы-клиенты. Для того чтобы программные процессы, существую- щие в узле-клиенте, могли выполнять операции с «экспортируемыми» файлами, содержащие эти файлы поддеревья должны быть смонтированы с файловой структурой узла-клиента.
Получив системный вызов МОНТИРОВАТЬ, виртуальная ФС в узле- клиенте начинает с того, что по первому параметру системного вызова опреде- ляет тип монтируемой системы – nfs. Далее в список монтирования добавля- ется новый элемент (информационная часть nfs), а указатель на этот элемент помещается в тот vnode, который соответствует точке монтирования. После этого виртуальная ФС вызывает процедуру инициализации реальной ФС nfs.
Данная процедура (как и другие процедуры nfs) выполняет свои функции, об- мениваясь сообщениями с удаленной серверной частью nfs. При этом адрес требуемого узла-сервера определяется из параметра системного вызова МОН-
ТИРОВАТЬ
, который соответствует разделу монтируемой системы. При монти- ровании удаленной ФС этот параметр содержит не имя раздела, а полное сете- вое имя того каталога, который является корнем монтируемого поддерева файловой структуры.
Запрос с просьбой разрешить монтирование посылается в требуемый узел-сервер с помощью модуля транспорта, имеющегося в узле-клиенте
(рис. 7.5). Приход этого сообщения инициирует процесс ядра «nfs-сервер», ко- торый большую часть времени находится в заблокированном состоянии. Реали- зация nfs-сервера в виде процесса обусловлена тем, что программа процесса в отличие от процедур не должна «подсоединяться» к программе какого-то дру- гого процесса, выдавшего системный вызов. Реализация процесса «nfs- сервер» вне ядра, то есть в виде демона, привела бы к существенному сниже- нию производительности сетевой ФС, так как данный процесс был бы вынуж-

209 ден конкурировать за время ЦП с обычными прикладными процессами. Суще- ственным отличием nfs-сервера от nfs-клиента и от программных частей дру- гих реальных ФС является то, что не виртуальная ФС инициирует этот модуль, а наоборот. При этом nfs-сервер играет роль своеобразного имитатора интер- фейса системных вызовов.
Рис. 7.5  Распределенная реальная файловая система nfs
При получении сообщения, содержащего просьбу о монтировании, nfs- сервер передает в свою виртуальную ФС команду проверить правомочность за- прашиваемой операции. Если проверка оказалась успешной, виртуальная ФС возвращает в nfs-сервер содержимое того vnode, который соответствует кор- ню монтируемого поддерева. Далее это содержимое посылается nfs-клиенту в виде сообщения по сети. Получив это сообщение, nfs-клиент завершает мон- тирование, создав свой inode для корня монтируемого поддерева файловой структуры, расположенного в другом узле сети. Данный inode включает среди прочей информации содержимое удаленного vnode.
Напомним, что среди прочей информации vnode имеет два поля, содер- жимое которых выполняет роль уникального имени файла в пределах данного