Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Акуленок_часть1.doc
Скачиваний:
41
Добавлен:
13.11.2019
Размер:
1.43 Mб
Скачать

4.7. Системная таблица файлов

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

  • суперблок;

  • индексный дескриптор;

  • каталоги файлов;

  • обычные файлы;

  • специальные файлы.

В нормальных условиях с ними работает ядро, а при необходимости восстановления файловой системы – программы fsck и fsdb.

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

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

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

Каждый элемент системной таблицы файлов содержит:

  • признак, показывающий, как был открыт файл (на чтение, на запись);

  • счетчик процессов, ссылающихся на этот элемент (когда значение счетчика становится равным нулю, система удаляет элемент);

  • указатель на элемент системной таблицы описателей файлов;

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

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

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

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

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

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

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

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

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

Рис. 4.5. Файловая система до монтирования

Для присоединения мы должны указать, в какое место существующей файловой системы (точку монтирования) следует смонтировать новую систему. После монтирования все каталоги новой файловой системы будут доступны в качестве подкаталогов точки монтирования. При этом истинная структура файловой системы оказывается прозрачной для пользователя. После того как система будет смонтирована, пользователь не отличит каталоги одной файловой системы от каталогов другой файловой системы. Предположим, мы смонтировали новую файловую систему в каталог /usr. Обе системы показаны на рис. 4.6.

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

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

$ mount

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

При старте системы после загрузки ядра и запуска процесса init инициируется проверка тех файловых систем, которые следует проверить и смонтировать автоматически. Файловые системы могут монтироваться автоматически, если они определены в специальных файлах. Для разных реализаций UNIX эти файлы могут называться по-разному. Например, для ОС Solaris – /etc/vfstab, для OC Linux – /etc/filesystems. В других системах UNIX этот файл имеет другое название – /etc/fstab.

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

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

mount device mount_point

Например:

$ mount /dev/dsk/c0d1s0 /test