Лекция 2. 10.02.2014

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

Физический уровень – аппаратное хранение файлов.

Символьный уровень – уровень именования файлов с точки зрения пользователя. Привычные для пользователя способы именования. Любое имя – набор символов. Полное имя файла – путь к файлу и его имя. Разные ОС накладывают разные требования на имена файлов. Системы поддерживают текущую директорию. Система сама дописывает к имени файла недостающий путь. В Юникс имя файла не является его атрибутом. Т. н. «этикетка» к файлу. Хард линк. На символьном уровне файл не имеет уникального имени.

Базовый уровень. Дескриптор файла. Структура или несколько структур, которые позволяют однозначно идент. Файл в системе. Базовый уровень обеспечивает идент-ю любого файла любой файловой системы.

Винд и юникс поддерживают сразу несколько ФС. Для того, чтобы поддерживать несколько ФС разработан интерфейс Virtual File System/vnode.

Уровень проверки прав доступа.

Логический уровень. Можно провести аналогию с процессом (процесс – программа в стадии выполнения). Процесс идентифицируется в системе дескриптором (struct proc). Процесс получает адресное пространство (карты трансляции адресов). Система большее время выполнения процесса оперирует виртуальными адресами. Преобразование виртуального адреса к физическому выполняется в последний момент.

Файл можно представить, как непрерывное виртуальное адресное пространство. Различаются два вида файлов: байт-ориентированные и блок-ориентированные – способы организации потоков информации. Связано с буферизацией. (В Паскале: текстовые и типизированные, в Си: текстовые и бинарные). Логический уровень позволяет преобразовать виртуальный адрес записи к физическому адресу. Делается это через подсистему ввода-вывода. Подсистема предназначена для взаимодействия определенных уровней системного ПО с низ лежащими уровнями системного ПО и с аппаратной частью. Жесткий диск – внешнее устройство.

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

Существует небольшой набор основных системных вызовов для работы с файлами: open, read, write, close, dup, create. Open может вызывать create, если файл не существует. К любому устройству можно обратиться используя эти системные вызовы.

Для приведения понятия системного устройства к понятию файла вводится понятие «специального файла». В Юникс все файл.

ВФС основана на 4 основных типах объектов:

1. Суперблок – superblock – является точкой входа любой файловой системы. Содержит информацию, которая описывает определенную ФС. Суперблок хранится в спец.секторе диска, т.е. он хранится на устройстве.

2. Inode

3. Dentry

4. File

Struct super_block

{

Struct list_head s_list; // список всех суперблоков

…

Struct super_operations *s_op; // операции, определенные в данном суперблоке

…

Struct dentry *s_root; // каталог или точка монтирования

…

Struct list_head s_inode; //список индексов

…

Struct list_head s_dirty;// список измененных индексов

}

Код находится в файле fs/super.c

Объект суперблок создается функцией alloc_super(); которая вызывается при монтировании ФС.

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

Usr sys dev etc bin - корневая ФС

Local adm users bin

Для того, чтобы иметь возможность монтировать ФС разработчики изменили системный вызов mount.

В SVF4 вызов mount выглядит следующим образом:

Mount(spec, dir, flags, type, dataptr, datalen);

Spec – имя файла устройства, представляющего ФС.

Dir – полное имя каталога, явл-ся точкой монтирования

Type – тип ФС.

Dataptr – указатель на дополнительные аргументы, зависящие от ФС.

Datalen – длина блока дополнительных параметров.

Рис. 2

Группа блоков n

Группа блоков 2

Группа блоков 1

Загрузочная запись

…

Супер-блок

Group description

Данные

inode Bitmap

Block Bitmap

Каждая группа блоков имеет одинаковую организацию

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

Дескриптор группы блоков.

Блок Bitmap – структура, каждый бит которой показывает, отведен ли соответствующий блок какому-либо файлу. Если в бите установлена 1, то блок занят.

Битовая карта inode’ов. Битовая карта индексных дескрипторов. Также позволяет определить заняит или свободет соответствующий индексный дескриптор.

Struct super_operation s_op - содержит указатель на таблицу операций (из struct superblock).

Каждое поле этой структуры является указателем на функцию, которая может использоваться для работы с суперблоком. Если какая-то функция в конкретной ФС не используется, то вместо указателя будет стоять null.

Операции над СБ вызываются следующим образом:

Sb->s_op->write_super(sb);

Inode.

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

Рисунок «дескриптор файла» в конце лекций 5 сем.

15 полей, каждое поле по 4 байта. 12 используются для непосредственной адресации.

12-ое поле – простая косвенная адресация. (1024 записи)

13-ое поле – двойная косвенная адресация.

14-ый блок – тройная косвенная адресация.

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

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

Структура strcut inode определена в файле <linux/fs.h>

Struct inode

{

Struct inode_operations *i_op; //указатель на таблицу операций с inode’ом

…

Union

{

Struct pipe_inode *i_pipe;

Struct block_device *i_bdev;

Strcut cdev *i_dev;

};

Файловый индекс inode создается в памяти в момент доступа к файлу.

Dentry – directory entry.

В VFS каталоги обрабатываются как особый тип файлов.

Пример: /bin/vi – bin явл каталогом, vi – файлом.

Оба эти типа файлов представляются в виде объекта файлового индекса inode. В VFS нужно выполнить операции, специфичные для каталогов, такие как поиск компонентов пути до имени этого пути. Для этого необходимо проанализировать каждый компонент пути, проверить, существует ли он, и, если существует, то перейти к следующему компоненту. Именно для этого в ВФС реализована концепция элемента каталога dentry. В примере имеется несколько элементов пути: «/», “bin”, “vi”. Каждый элемент является объектом dentry. Перед созданием dentry выполняется обработка строки.

Структура struct dentry

{

Atomic_t d_count;

…

Struct inode *d_inode;

Struct dentry *d_parent; // указатель на родительский каталог

…

Struct list_head d_child;

Struct list_head d_subdirs; // указатели на директории

…

Int d_mounted;

Struct qstr d_name; // истинное имя dentry

…

Struct dentry_operations *d_op; // указатель на таблицу функций, определенных на каталогах

};

Atomic – операции с такими данными являются неделимыми.