Андрей Робачевский - Операционная система UNIX

Описанная архитектура является весьма эффективной с точки зрения надежности и производительности. К сожалению, эти параметры файловой системы FSS начинают значительно ухудшаться по мере уменьшения свободного места. В этом случае системе не удается следовать вышеприведенным правилам и размещение блоков далеко от оптимального. Практика показывает, что FSS имеет удовлетворительные характеристики при наличии более 10% свободного места.

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

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

Рис. 4.6. Каталог файловой системы FFS

Как было показано, различные типы файловых систем существенно отличаются по внутренней архитектуре. В то же время современные версии UNIX обеспечивают одновременную работу с несколькими типами файловых систем. Среди них можно выделить локальные файловые системы различной архитектуры, удаленные и даже отличные от файловой системы UNIX, например DOS. Такое сосуществование обеспечивается путем разделения каждой файловой системы на зависимый и независимый от реализации уровни, последний из которых является общим и представляет для остальных подсистем ядра некоторую абстрактную файловую систему. Независимый уровень также называется виртуальной файловой системой (рис. 4.7). При этом дополнительные файловые системы различных типов могут быть встроены в ядро UNIX подобно тому, как это происходит с драйверами устройств.

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

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

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

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

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

Таблица 4.1. Поля vnode

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