г-узел и зону, передаваемых из суперблока в alloc bit как начальная позиция для поиска, его удается подсократить.

Обнулить занятый бит проще, чем установить, так как не требуется выполнять поиск. Функция free bit вычисляет, какой блок битовой карты содержит сбрасываемый бит, и дальше вызывает get block, обнуляет бит и завершает операцию вызовом put block.

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

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

Наконец, перейдем к read super. Эта функция частично подобна функциям rw block и rwjnode, но выполняет только чтение. Записывать суперблок при нормальной работе системы не требуется. Считав суперблок, функция read super узнает версию файловой системы и при необходимости выполняет форматное преобразование. Таким образом, копия суперблока в памяти всегда имеет стандартный формат, даже если она прочитана с диска с другой структурой.

Работа с дескрипторами файлов

в MINIX имеются специальные подпрограммы и для работы с файловыми дескрипторами и таблицами filp (см. рис. 5.29). Эти процедуры находятся в файле filedesc.c. Когда файл создается или открывается, с ним связываются свободный дескриптор и незанятая ячейка в таблице filp. Для поиска свободных ресурсов предназначена процедура getjd. Она не помечает их как занятые, так как успешному завершению вызовов creat или open предшествует еще множество различных проверок.

Функция get filp проверяет, находится ли файловый дескриптор в заданных пределах и возвращает его указатель, взятый из filp.

Последняя процедура в файле, find filp, позволяет выяснить, что процесс пытается писать в неработающий канал (то есть канал, не открытый другим процессом на чтение). Она прямым перебором ищет в таблице filp процессы-читатели на другом конце канала. Если такой процесс найти не удалось, значит, канал разрушен и попытка записи в него обречена на провал.

Захват файлов

Функции POSIX для захвата файлов перечислены в табл. 5.8. Участок файла можно захватить на запись и чтение или только на запись при помощи системного вызова fcntl с запросом F SETLK или F SETLKW. Узнать, удерживается ли кем тот или иной участок файла, можно с помощью запроса F GETLK.

Таблица 5.8. Операции захвата записей согласно POSIX

Операция Действие

F SETLK Захватывает область на запись и чтение

F SETLKW Захватывает область на запись

F GETLK Проверяет, свободна ли область

В lock.c есть только две функции. К первой из них, 1оск ор, обращается системный вызов fcntl при выполнении каждой из операций, перечисленных в таблице. Она делает несколько тестов, гарантирующих, что участок задан корректно. Блокировка участка не должна конфликтовать с существующими, а другой захват не должен быть выполнен дважды. Для снятия захвата вызывается другая процедура из этого файла, lock revive. Она разблокирует все процессы, ранее заблокированные в ожидании данного участка. Это компромиссная стратегия, потому для точного решения, какой процесс получит управление, потребовался дополнительный код. Те процессы, время которых еще не наступило, вновь блокируются после запуска. Такая стратегия выбрана исходя из того предположения, что захват файлов - операция редкая. Если на основе MINIX будет построена многопользовательская база данных, не исключено, что потребуется изменить данный алгоритм.

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

5.7.3. Основная программа

Код главного цикла файловой системы находится в файле main.c. По своей структуре он очень схож с главным циклом менеджера памяти и задач ввода/вывода. В нем вызывается функция get work, ожидающая прибытия следующего запроса на обслуживание (если не может быть обслужен процесс, ранее приостановленный на чтении из канала или с терминала). Она же устанавливает значение глобальной переменной who, куда записывается номер ячейки в таблице процессов, принадлежащей вызывающему процессу, а также заполняет другую глобальную переменную, fs call, записывая в нее номер сделанного системного вызова.

Как только управление возвращается в главный цикл, устанавливаются три флага: fp указывает на запись вызывающего процесса в таблице процессов, super user говорит, принадлежит ли этот процесс суперпользователю, dont reply инициализируется значением FALSE. Затем начинается главное действо: на передний план выходит процедура, выполняющая системный вызов. Адрес процедуры определяется по номеру системного вызова из таблицы указателей на процедуры, calLvector.

При возврате управления в главный цикл проверяется значение флага dont reply. Если он установлен, значит, ответное сообщение не требуется (то есть процесс заблокирован по причине чтения из пустого канала). Иначе отправляется ответное сообщение. Последний оператор в цикле должен распознавать последо-

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

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

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

Функции инициализации

Оставшуюся часть файла main.c составляют функции инициализации, отрабатывающие при запуске системы. Перед входом в главный цикл файловая система инициализирует себя, вызывая fsjnit, которая, в свою очередь, вызывает несколько других функций с целью подготовить кэш блоков, определить параметры загрузки ядра, при необходимости организовать RAM-диск, а также загрузить суперблок корневого устройства. На следующем шаге заполняется принадлежащая файловой системе часть таблицы процессов, в нее вносятся записи всех серверов и задач, до процесса init. Наконец, проверяются значения некоторых важных констант, чтобы узнать, осмысленны ли их значения, и задаче памяти отправляется сообщение, в котором передается адрес таблицы процессов в файловой системе. Впоследствии этот адрес может использоваться программой ps.

Сначала ftjnit вызывает buf pool, формирующую списки для кэширования блоков. На рис. 5.27 показано нормальное состояние кэша, где все блоки связаны друг с другом в LRU-список и хешированы. Полезно разобраться в том, откуда берется ситуация, показанная на рисунке. Сразу после инициализации процедурой buf pool все буферы находятся в списке и все они сцеплены в нулевую хеш-цепочку, как показано на рис. 5.30, а. Когда запрашивается буфер, структура приходит в состояние, показанное на рис. 5.30, б, и остается в нем, пока буфер используется. На этом рисунке мы можем видеть, что блок исключен из LRU-списка и помещен в отдельную хеш-цепочку. Обычно же блок освобождается и возвращается в LRU-список немедленно. Эта ситуация иллюстрируется рис. 5.30, в. Здесь блок, хотя и не используется более, все еще содержит информацию, и при необходимости может быть извлечен из хеш-цепочки. После того как система поработает некоторое время, почти все блоки, скорее всего, окажутся случайно распределены между различными цепочками. Список LRU при этом будет выглядеть в соответствии с рис. 5.27.

Следующая функция, get boot parameters, запрашивает у задачи системы параметры загрузки ядра. Эти значения необходимы функции load ram, выделяющей память для RAM-диска. Если при загрузке ядру передан параметр rootdev = ram

корневая файловая система блок за блоком копируется на RAM-диск (устройство ramimagedev), различные структуры файловой системы не интерпретируются.