Московский физико-технический институт
Опубликован: 16.09.2004 | Доступ: свободный | Студентов: 7357 / 1504 | Оценка: 4.44 / 4.28 | Длительность: 15:33:00
Лекция 8:

Организация файловой системы в UNIX. Работа с файлами и директориями. Понятие о memory mapped файлах

Аннотация: Разделы носителя информации (partitions) в UNIX. Логическая структура файловой системы и типы файлов в UNIX. Организация файла на диске в UNIX на примере файловой системы s5fs. Понятие индексного узла (inode). Организация директорий (каталогов) в UNIX. Понятие суперблока. Операции над файлами и директориями. Системные вызовы и команды для выполнения операций над файлами и директориями. Системный вызов open(). Системный вызов close(). Операция создания файла. Системный вызов creat(). Операция чтения атрибутов файла. Системные вызовы stat(), fstat() и lstat(). Операции изменения атрибутов файла. Операции чтения из файла и записи в файл. Операция изменения указателя текущей позиции. Системный вызов lseek(). Операция добавления информации в файл. Флаг O_APPEND. Операции создания связей. Команда ln, системные вызовы link() и symlink(). Операция удаления связей и файлов. Системный вызов unlink(). Специальные функции для работы с содержимым директорий. Понятие о файлах, отображаемых в память (memory mapped файлах). Системные вызовы mmap(), munmap().
Ключевые слова: Unix, раздел (partition) или логический диск, слово, разбиение, форматирование, пользователь, MS-DOS, файловая система, определение, представление, Директория, регулярный файл, файл типа FIFO, PIPS, файл устройства, пространство, FIFO, функция, mkfifo, файл типа "связь", операция над файлом, операции, файл типа "сокет", ациклический, граф файловой системы, ребро, имя файла, полное имя файла, ПО, файл, system, файловая система s5fs, заголовок раздела, индексный узел (inode), INDEX, node, атрибут файла, массив индексных узлов, System V IPC, индексный дескриптор, информация, пространство имен, байт, родительский каталог, размерность, FFS, длина, суперблок, флаг состояния, адресное пространство, список, операционная система, место, доступ, rewind, права доступа, объединение, интерфейс, операция над директорией, symbolic link, терминальная вершина, команда chmod, команда chown, команда chgrp, команда cp, команда rm, команда mv, команда ls, таблица открытых файлов процесса, системный вызов open(), системный вызов close(), системный вызов read(), системный вызов write(), системный контекст, PCB, указатель текущей позиции, значение, системная таблица открытых файлов, таблица индексных узлов открытых файлов, очередь, индекс, дескриптор, pipe, таблица, пользовательский процесс, права, пустой элемент, связь, отображение, системный вызов, счетчик, системный вызов creat(), относительное имя файла, маска создания файлов текущего процесса, системный вызов stat(), системный вызов fstat(), системный вызов lstat(), жесткая связь, мягкая или символическая связь, символьное устройство, блочное устройство, системный вызов ftruncate(), размер файла, конец файла, системный вызов lseek(), запись, открытие файла, команда ln, системный вызов link(), системный вызов symlink(), создание файла, Задача синхронизации, hard, целостность, атрибут, root, команда, имя связи, указатель, системный вызов unlink(), функция opendir(), функция readdir(), функция rewinddir(), функция closedir(), параметр, manual, файл, отображаемый в память (memory mapped файл), системный вызов mmap(), системный вызов munmap(), программа, анализ, компиляция, память

Введение

В материалах нескольких предыдущих семинаров (семинары 1–2, семинар 5) уже затрагивались вопросы работы с файлами в UNIX. Но только теперь, пояснив в лекции понятие файловой системы, мы можем рассмотреть файловую систему UNIX в целом. Наш обзор, правда, ограничится общими вопросами, связанными с организацией файловой системы, и системными вызовами, которые с наибольшей вероятностью могут пригодиться в дальнейшем. Это связано как с ограниченностью времени, которое отводится на работу с файловыми системами в нашем курсе, так и с преимущественно практическим направлением наших занятий.

Разделы носителя информации (partitions) в UNIX

Физические носители информации – магнитные или оптические диски, ленты и т.д., использующиеся как физическая основа для хранения файлов, в операционных системах принято логически делить на разделы (partitions) или логические диски . Причем слово "делить" не следует понимать буквально, в некоторых системах несколько физических дисков могут быть объединены в один раздел. Об этом подробнее рассказывается в лекции 12 в разделе "Общая структура файловой системы".

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

Наличие нескольких разделов на диске может определяться требованиями операционной системы или пожеланиями пользователя. Допустим, пользователь хочет разместить на одном жестком диске несколько операционных систем с возможностью попеременной работы в них, тогда он размещает каждую операционную систему в своем разделе. Или другая ситуация: необходимость работы с несколькими видами файловых систем. Под каждый тип файловой системы выделяется отдельный логический диск. Третий вариант – это разбиение диска на разделы для размещения в разных разделах различных категорий файлов. Скажем, в одном разделе помещаются все системные файлы, а в другом разделе – все пользовательские файлы. Примером операционной системы, внутренние требования которой приводят к появлению нескольких разделов на диске, могут служить ранние версии MS-DOS, для которых максимальный размер логического диска не превышал 32 Мбайт.

Для простоты далее в этих семинарах будем полагать, что у нас имеется только один раздел и, следовательно, одна файловая система. Вопросы взаимного сосуществования нескольких файловых систем в рамках одной операционной системы мы затронем в семинарах 13–14 перед обсуждением реализации подсистемы ввода-вывода.

Логическая структура файловой системы и типы файлов в UNIX

Мы не будем давать здесь определение файла, полагая, что интуитивное представление о файлах у вас имеется, а в лекции 11 (раздел "Введение") было введено понятие о файлах, как об именованных абстрактных объектах, обладающих определенными свойствами. При этом в пространстве имен файлов одному файлу могут соответствовать несколько имен.

В материалах семинаров 1-2 упрощенно говорилось о том, что файлы могут объединяться в директории, и что файлы и директории организованы в древовидную структуру. На нынешнем уровне знаний мы можем сформулировать это более аккуратно. В операционной системе UNIX существуют файлы нескольких типов, а именно:

  • обычные или регулярные файлы ;
  • директории или каталоги;
  • файлы типа FIFO или именованные pip'ы;
  • специальные файлы устройств ;
  • сокеты (sockets);
  • специальные файлы связи (link).

Что такое регулярные файлы и директории, вам должно быть хорошо известно из личного опыта и из лекций (лекция 11). О способах их отображения в дисковое пространство речь пойдет чуть позже. Файлы типа FIFO были представлены в семинаре 5, когда рассматривалась работа с именованными pip'ами (раздел "Понятие FIFO. Использование системного вызова mknod() для создания FIFO. Функция mkfifo()"). Файлы типа "связь" мы представим в этом семинаре, когда будем обсуждать операции над файлами (раздел "Операции над файлами и директориями ") и соответствующие им системные вызовы (раздел "Системные вызовы и команды для выполнения операций над файлами и директориями "). О специальных файлах устройств будет рассказано в материалах семинаров 13–14, посвященных реализации в UNIX подсистемы ввода-вывода и передаче информации с помощью сигналов. Файлы типа "сокет" будут введены в семинарах 15–16, когда мы будем рассматривать вопросы сетевого программирования в UNIX.

Файлы всех перечисленных типов логически объединены в ациклический граф с однонаправленными ребрами, получающийся из дерева в результате сращивания нескольких терминальных узлов дерева или нескольких его нетерминальных узлов таким образом, чтобы полученный граф не содержал циклов. В нетерминальных узлах такого ациклического графа (т.е. в узлах, из которых выходят ребра) могут располагаться только файлы типов " директория " и "связь". Причем из узла, в котором располагается файл типа "связь", может выходить только ровно одно ребро. В терминальных узлах этого ациклического графа (т.е. в узлах, из которых не выходит ребер) могут располагаться файлы любых типов (см. рис. 11–12.1), хотя присутствие в терминальном узле файла типа "связь" обычно говорит о некотором нарушении целостности файловой системы.

Пример графа файловой системы

Рис. 11-12.1. Пример графа файловой системы

В отличие от древовидной структуры набора файлов, где имена файлов связывались с узлами дерева, в таком ациклическом графе имя файла связывается не с узлом, соответствующим файлу, а с входящим в него ребром. Ребра, выходящие из узлов, соответствующих файлам типа "связь", являются неименованными. Надо отметить, что практически во всех существующих реализациях UNIX-подобных систем в узел графа, соответствующий файлу типа " директория ", не может входить более одного именованного ребра, хотя стандарт на операционную систему UNIX и не запрещает этого. Правила построения имен ребер (файлов) рассматривались в семинарах 1-2. В качестве полного имени файла может использоваться любое имя, получающееся при прохождении по ребрам от корневого узла графа (т.е. узла, в который не входит ни одно ребро) до узла, соответствующего этому файлу, по любому пути с помощью следующего алгоритма:

  1. Если интересующему нас файлу соответствует корневой узел, то файл имеет имя " / ".
  2. Берем первое именованное ребро в пути и записываем его имя, которому предваряем символ " / ".
  3. Для каждого очередного именованного ребра в пути приписываем к уже получившейся строке справа символ " / " и имя соответствующего ребра.

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