2.7 Файловые системы

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

Компонент под названием имя файла является строкой длиной до 255 символов. Эти имена хранятся в файле особого типа, который называется каталогом. Информация о файле в каталоге называется записью каталога и включает, кроме имени файла, указатель на сам файл. Записи каталога могут ссылаться как на другие каталоги, так и на обычные файлы. Таким образом формируется иерархия каталогов и файлов, которая и называется файловой системой filesystem;

Одна небольшая файловая система показана на Figure 2-2. Каталоги могут содержать подкаталоги, и нет ограничений вложенности одного каталога в другой по глубине. Для соблюдения целостности файловой системы, ядро не позволяет процессу производить запись непосредственно в каталоги. Файловая система может хранить не только обычные файлы и каталоги, но также ссылки на другие объекты, такие, как устройства и сокеты.

Файловая система образует дерево, начало которого находится в корневом каталоге, иногда называемому по имени слэш, которое соответствует символу одинарной наклонной черты (/). Корневой каталог содержит файлы; в нашем примере на Рисунке 2.2, он содержит vmunix, копию выполнимого объектного файла ядра. В нем также расположены каталоги; в этом примере он содержит каталог usr. Внутри каталога usr располагается каталог bin, который в основном содержит выполнимый объектный код программ, таких, как ls и vi.

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

Имя пути, которое не начинается со слэша, называется относительным маршрутом, и интерпретируется относительно текущего рабочего каталога процесса. (Этот каталог кратко также называют текущим каталогом или рабочим каталогом.) Текущий каталог сам по себе можно обозначить непосредственно по имени dot, что соответствует одной точке (.). Имя файла dot-dot (..) обозначает родительский каталог текущего каталога. Корневой каталог является предком самому себе.

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

Взяв файловую систему, изображенную на Рисунке 2.2, и полагая, что процесс имеет в качестве корневого каталога корневой каталог файловой системы, и в качестве текущего каталога /usr, он может обратиться к файлу vi либо от корня по абсолютному имени /usr/bin/vi, либо из текущего каталога с относительным именем bin/vi.

Системные утилиты и базы данных располагаются в нескольких всем известных каталогах. Частью предопределенной иерархии является каталог, содержащий домашний каталог для каждого пользователя -- например, /usr/staff/mckusick и /usr/staff/karels на Рисунке 2.2. Когда пользователи регистрируются в системе, то рабочий каталог их командного процессора устанавливается в домашний каталог. В своих домашних каталогах пользователи могут создавать каталоги так же легко, как и обычные файлы. Таким образом, пользователь может строить иерархии каталогов произвольной сложности.

Пользователь обычно знает только об одной файловой системе, но система может знать, что одна виртуальная файловая система на самом деле состоит из нескольких физических файловых систем, каждая из которых расположена на отдельном устройстве. Физическая файловая система не может располагаться на нескольких физических устройствах. Так как большинство физических дисковых устройств разбиваются на несколько логических устройств, то на одном физическом устройстве может располагаться более одной файловой системы, но не более одной для каждого логического устройства. Одна из файловых систем -- та, с которой начинаются все абсолютные имена -- называется корневой файловой системой, и она всегда доступна. Другие файловые системы могут монтироваться; это значит, что они могут интегрироваться в иерархию каталогов корневой файловой системы. Ссылки на каталог, в котором находится смонтированная в него файловая системе, прозрачно преобразуются ядром в ссылки на корневой каталог смонтированной файловой системы.

Системный вызов link в качестве параметров принимает имя существующего файла и новое имя, которое будет присвоено файлу. После успешного выполнения вызова link, файл может быть доступен по любому из имен. Имя файла может быть удалено при помощи системного вызова unlink. Когда удаляется последнее имя для файла (и последний процесс, который держал файл открытым, закрыл его), удаляется и сам файл.

Файлы организованы иерархически в каталоги. Каталог является типом файла, но, в отличие от обычных файлов, каталог имеет структуру, определяемую системой. Процесс может читать каталог, как будто это обычный файл, но только ядру разрешено изменять каталог. Каталоги создаются системным вызовом mkdir и удаляются системным вызовом rmdir. До 4.2BSD системные вызовы mkdir и rmdir были реализованы как последовательность системных вызовов link и unlink. Имелось три причины для добавления системных вызовов специально для создания и удаления каталогов:

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

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

3. При реализации поддержки не-UNIX файловых систем, таких, как файловая система MS-DOS, на другом разделе диска, может оказаться, что эта файловая система не поддерживает ссылочных операций. Хотя другие файловые системы могут поддерживать концепцию каталогов, скорее всего, они не будут создавать и удалять каталоги со ссылками, как это делается в файловой системе UNIX. Соответственно они могут создавать и и удалять каталоги только при наличии явных запросов на удаление или создание каталогов.

Системный вызов chown устанавливает владельца и группу файла, а chmod изменяет атрибуты защиты. Вызов stat, примененный к имени файла, может использоваться для чтения этих свойств файла. Системные вызовы fchown, fchmod и fstat применяются с дескрипторами, а не с именами файлов, для выполнения того же самого набора операций. Системный вызов rename может использоваться для присвоения файлу нового имени в файловой системе с заменой старого имени файла. Как и операции по созданию и удалению каталогов, системный вызов rename был добавлен в 4.2BSD для придания атомарности изменению имен в локальной файловой системе. Позже он оправдал свою исключительную полезность для экспортирования операций по переименованию в сторонних файловых системах и по сети.

Системный вызов truncate был добавлен в 4.2BSD для того, чтобы файлы могли обрезаться по указанному смещению. Вызов был добавлен первоначально для поддержки библиотеки времени выполнения языка Fortran, в котором применялось понятие конца файла с произвольным доступом, который мог устанавливаться в любую позицию, в которой был последний раз доступ к файлу. Без системного вызова truncate единственным способом обрезать файл было копирование нужной части в новый файл, удаление старого и переименование копии в первоначальное имя. Библиотека могла теоретически отказываться работать на заполненной файловой системе, к тому же такой алгоритм оказывался медленным.

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

Вновь создаваемым файлам присваивается идентификатор пользователя процесса, который их создал, и идентификатор группы каталога, в котором они были созданы. Для защиты файлов применяется трехуровневый механизм управления доступом. Эти три уровня определяют доступность файла для

1. Пользователя, который является владельцем файла

2. Группы, которая приписана файлу

3. Всех остальных

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

Файлы создаются с нулевым размером, который может увеличиться при выполнении операций записи. Пока файл открыт, система отслеживает указатель на файл, соответствующий текущему положению в файле, связанном с дескриптором. Этот указатель может перемешаться по файлу в произвольном порядке. Процессы, использующие один и тот же дескриптор файла посредством системных вызовов fork или dup, используют одновременно один и тот же указатель текущей позиции. Дескрипторы, созданные различными системными вызовами open, имеют различные указатели текущей позиции. В файлах могут присутствовать дыры. Дыры представляют собой пустые пространства в теле файла, в которые никаких данных не записывалось. Процесс может создать такие дыры, перемещая указатель за текущий конец файла и производя запись. При чтении дыры интерпретируются системой как заполненные нулевыми байтами.

Ранние версии UNIX имели ограничение в 14 символов на имя файла. Это ограничение зачастую вызывало проблемы. Например, кроме естественного желания пользователей давать файлам длинные описательные имена, распространенным способом формировать имена файлов является использование формата basename.extension, где расширение (указывающее на тип файла, скажем, .c для исходного года на языке C или .o для промежуточного двоичного объекта) имеет длину от одного до трех символов, оставляя от 10 до 12 символов на имя файла. Системы управления исходным кодом и редакторы обычно используют дополнительно два символа для своих целей, для префикса или суффикса имени файла, при этом остается от восьми до 10 символов. В качестве имени файла легко использовать от 10 до 12 символов одного английского слова (например, ``multiplexer'').

Можно смириться с этими ограничениями, но это непоследовательно и даже опасно, потому что другие системы UNIX могут работать со строками, превышающими этот лимит, при создании файлов, но затем имя будет обрезано. Исходный файл с именем multiplexer.c, содержащий исходный код на языке C, (уже 13 символов) может иметь соответствующий файл из системы управления исходным кодом с префиксом s., при этом получается имя файла s.multiplexer, которое не не будет отличаться от файла системы управления исходным кодом для файла multiplexer.ms, содержащего исходный код troff для документации программы на языке C. Содержимое двух оригинальных файлов может оказаться перепутанным без каких-либо предупреждений от системы управления исходным кодом. При тщательном кодировании эту проблему можно обнаружить, но поддержка длинных имен файлов, впервые появившаяся в 4.2BSD, практически полностью ликвидировала эту проблему.