Принципы построения файловых систем семейства UNIX

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Занятие 1

Принципы построения файловых систем семейства UNIX

• Содержание занятия
• 1. Теоретическая часть. Файловые системы семейства UNIX
• 1.1 Общие сведения
• 1.2 Базовая файловая система System V
• 1.3 Суперблок
• 1.4 Индексные дескрипторы
• 1.5 Недостатки и ограничения
• 1.6 Файловая система BSD UNIX
• 1.7 Dиртуальная файловая система
• 1.8 Виртуальные индексные дескрипторы
• 1.9 Операции vnode
• 1.10Монтирование файловой системы
• 1.11 Трансляция имен
• 1.12 Доступ к файловой системе
• 1.13 Файловые дескрипторы
• 1.14 Файловая таблица
• 1.15 Блокирование доступа к файлу
• 1.16 Буферный кэш
• 1.17 Внутренняя структура буферного кэша
• 1.18 Кэширование в SVR4
• 1.19 Целостность файловой системы
• Заключение
• 1. Теоретическая часть. Файловые системы семейства UNIX
• 1.1 Общие сведения
• Большинство данных в операционной системе UNIX хранится в файлах, организованных в виде дерева и расположенных на некотором носителе данных. Обычно это локальный (т.е. расположенный на том же компьютере, что и сама операционная система) жесткий диск, хотя специальный тип файловой системы -- NFS (Network File System) обеспечивает хранение файлов на удаленном компьютере. Файловая система также может располагаться на CD-ROM, дискетах и других типах носителей, однако для простоты изложения сначала мы рассмотрим традиционную файловую систему UNIX, расположенную на обычном жестком диске компьютера. файл дескриптор буферный кэш
• Исконной файловой системой UNIX System V является s5fs. Файловая система, разработанная в Беркли, FFS, появилась позже, в версии 4.2BSD UNIX. По сравнению с s5fs она обладает лучшей производительностью, функциональностью и надежностью. Файловые системы современных версий UNIX имеют весьма сложную архитектуру, различную для разных версий. Несмотря на это все они используют базовые идеи, заложенные разработчиками UNIX в AT&T и Калифорнийском университете в Беркли. Поэтому мы проиллюстрируем основные принципы организации файловой системы UNIX на примере базовых систем System V (s5fs) и BSD (FFS), которые, кстати, и сегодня поддерживаются в большинстве версий UNIX.
• Когда появилась файловая система FFS, архитектура UNIX поддерживала работу только с одним типом файловой системы. Таким образом, создатели различных версий операционной системы UNIX вынуждены были выбирать одну файловую систему из нескольких возможных. Это неудобство было преодолено введением независимой или виртуальной файловой системы -- архитектуры, позволяющей обеспечивать работу с несколькими "физическими" файловыми системами различных типов. В этой главе мы рассмотрим реализацию виртуальной файловой системы, разработанную фирмой Sun Microsystems. Данная архитектура является стандартом для SVR4, однако и другие версии UNIX используют подобные подходы. В качестве примера можно привести независимую файловую систему SCO UNIX.
• Далее мы рассмотрим схему доступа прикладных процессов к файлам -- всю цепочку структур данных от файловых дескрипторов процесса до фактических дисковых данных, которую операционная система создает в результате открытия процессом файла и которая затем используется для обмена данными.
• В заключение мы рассмотрим буферный кэш -- подсистему, которая позволяет значительно увеличить производительность работы с дисковыми данными.
• 1.2 Базовая файловая система System V
• Каждый жесткий диск состоит из одной или нескольких логических частей, называемых разделами (partitions). Расположение и размер раздела определяются при форматировании диска. В UNIX разделы выступают в качестве независимых устройств, доступ к которым осуществляется как к различным носителям данных.
• Например, диск может состоять из четырех разделов, каждый из которых содержит свою файловую систему. Заметим, что в разделе может располагаться только одна файловая система, которая не может занимать несколько разделов. В другой конфигурации диск может состоять только из одного раздела, позволяя создание весьма емких файловых систем.

• Ри с. 1. Структура файловой системы s5fs
• Файловая система s5fs занимает раздел диска и состоит из трех основных компонентов, как показано на рис. 1.
• 1. Суперблок (superblock). Содержит общую информацию о файловой системе, например, об ее архитектуре, общем числе блоков и индексных дескрипторов, или метаданных (inode).
• 2. Массив индексных дескрипторов (ilist). Содержит метаданные всех файлов файловой системы. Индексный дескриптор содержит статусную информацию о файле и указывает на расположение данных этого файла. Ядро обращается к inode по индексу в массиве ilist. Один inode является корневым (root) inode файловой системы, через него обеспечивается доступ к структуре каталогов и файлов после монтирования файловой системы. Размер массива ilist является фиксированным и задается при создании файловой системы. Таким образом, файловая система s5fs имеет ограничение по числу файлов, которые могут храниться в ней, независимо от размера этих файлов.
• 3. Блоки хранения данных. Данные обычных файлов и каталогов хранятся в блоках. Обработка файла осуществляется через inode, содержащего ссылки на блоки данных. Блоки хранения данных занимают большую часть дискового раздела, и их число определяет максимальный суммарный объем файлов данной файловой системы. Размер блока кратен 512 байтам, например файловая система S51K SCO UNIX использует размер блока в 1 Кбайт (отсюда и название).
• Рассмотрим подробнее каждый из перечисленных компонентов.
• 1.3 Суперблок
• Суперблок содержит информацию, необходимую для монтирования и управления работой файловой системы в целом (например, для размещения новых файлов). В каждой файловой системе существует только один суперблок, который располагается в начале раздела. Суперблок считывается в память при монтировании файловой системы и находится там до ее отключения (размонтирования).
• Суперблок содержит следующую информацию:
• П Тип файловой системы (s_type)
• П Размер файловой системы в логических блоках, включая сам суперблок, ilist и блоки хранения данных (s_fsize)
• Размер массива индексных дескрипторов (s_isize)
• Число свободных блоков, доступных для размещения (s_tfree)
• Число свободных inode, доступных для размещения (s_tinode)
• Флаги (флаг модификации sfmod, флаг режима монтирования s_fronly)
• Размер логического блока (512, 1024, 2048) П Список номеров свободных inode П
• Список адресов свободных блоков
• Поскольку число свободных inode и блоков хранения данных может быть значительным, хранение двух последних списков целиком в суперблоке непрактично. Например, для индексных дескрипторов хранится только часть списка. Когда число свободных inode в этом списке приближается к О, ядро просматривает ilist и вновь формирует список свободных inode. Для этого ядро анализирует поле di_mocie индексного дескриптора, которое равно 0 у свободных inode.
• К сожалению, такой подход неприменим в отношении свободных блоков хранения данных, поскольку по содержимому блока нельзя определить, свободен он или нет. Поэтому необходимо хранить список адресов свободных блоков целиком. Список адресов свободных блоков может занимать несколько блоков хранения данных, но суперблок содержит только один блок этого списка. Первый элемент этого блока указывает на блок, хранящий продолжение списка и т. д., как это показано на рис. 1.
• Выделение свободных блоков для размещения файла производится с конца списка суперблока. Когда в списке остается единственный элемент, ядро интерпретирует его как указатель на блок, содержащий продолжение списка. В этом случае содержимое этого блока считывается в суперблок и блок становится свободным. Такой подход позволяет использовать дисковое пространство под списки, пропорциональное свободному месту в файловой системе. Другими словами, когда свободного места практически не остается, список адресов свободных блоков целиком помещается в суперблоке.
• 1.4 Индексные дескрипторы
• Индексный дескриптор, или inode, содержит информацию о файле, необходимую для обработки данных, т.е. метаданные файла. Каждый файл ассоциирован с одним inode, хотя может иметь несколько имен в файловой системе, каждое из которых указывает на один и тот же inode.
• Индексный дескриптор не содержит:
• - имени файла, которое содержится в блоках хранения данных каталога;
• - содержимого файла, которое размещено в блоках хранения данных.
• При открытии файла ядро помещает копию дискового inode в память в таблицу in-core inode, которая содержит несколько дополнительных полей. Структура дискового inode (struct dinode) приведена на рис. 2. Основные поля дискового inode следующие:
• di_mode Тип файла, дополнительные атрибуты выполнения и права доступа.
• di_niinks Число ссылок на файл, т. е. количество имен, которые имеет файл в файловой системе.
• di_uid, digid Идентификаторы владельца-пользователя и владельца группы.
• Рис. 2. Структура дискового inode
• di_size - Размер файла в байтах. Для специальных файлов это поле содержит старший и младший номера устройства.
• Di_atime - Время последнего доступа к файлу.
• Di_mtime Время последней модификации.
• Di_Ctime Время последней модификации inode (кроме модификации полей di_atime, di_mtime).
• Di_addr [13] Массив адресов дисковых блоков хранения данных
• Поле di_mode хранит несколько атрибутов файла: тип файла (IFREG для обычных файлов, IFDIR для каталогов, IFBLK или IFCHR для специальных файлов блочных и символьных устройств соответственно); права доступа к файлу для трех классов пользователей и дополнительные атрибуты выполнения (SUID, SGID и sticky bit), значения этих атрибутов были подробно рассмотрены в главе 1.
• Заметим, что в индексном дескрипторе отсутствует информация о времени создания файла. Вместо этого inode хранит три значения времени: время последнего доступа (di atime), время последней модификации содержимого файла (di mtime) и время последней модификации метаданных файла (di ctime). В последнем случае не учитываются модификации полей di_atime и di_mtime. Таким образом, di_ctime изменяется, когда изменяется размер файла, владелец, группа, или число связей.
• Индексный дескриптор содержит информацию о расположении данных файла. Поскольку дисковые блоки хранения данных файла в общем случае располагаются не последовательно, inode должен хранить физические адреса всех блоков, принадлежащих данному файлу1. В индексном дескрипторе эта информация хранится в виде массива, каждый элемент которого содержит физический адрес дискового блока, а индексом массива является номер логического блока файла. Массив имеет фиксированный размер и состоит из 13 элементов. При этом первые 10 элементов адресуют непосредственно блоки хранения данных файла. Одиннадцатый элемент адресует блок, в свою очередь содержащий адреса блоков хранения данных. Двенадцатый элемент указывает на дисковый блок, также хранящий адреса блоков, каждый из который адресует блок хранения данных файла. И, наконец, тринадцатый элемент используется для тройной косвенной адресации, когда для нахождения адреса блока хранения данных файла используются три дополнительных блока.
• Такой подход позволяет при относительно небольшом фиксированном размере индексного дескриптора поддерживать работу с файлами, размер которых может изменяться от нескольких байтов до десятка мегабайтов. Для относительно небольших файлов (до 10 Кбайт при размере блока 1024 байтов) используется прямая индексация, обеспечивающая максимальную производительность. Для файлов, размер которых не превышает 266 Кбайт (10 Кбайт + 256x1024), достаточно простой косвенной адресации. Наконец, при использовании тройной косвенной адресации можно обеспечить доступ к 16777216 блокам (256x256x256).
• Файлы в UNIX могут содержать так называемые дыры. Например, процесс может создать пустой файл, с помощью системного вызова lseek(2) сме-
• Размещение данных файла в произвольно расположенных дисковых блоках позволяет эффективно использовать дисковое пространство, поскольку ядро может использовать любой свободный дисковый блок для размещения данных. Однако в файловой системе s5fs блок может использоваться только одним файлом, поэтому последний блок файла используется, как правило, не полностью. К тому же такой подход с течением времени приводит к увеличению фрагментации системы, когда данные файла оказываются произвольно разбросанными по диску, что, в свою очередь, увеличивает время доступа к файлу и уменьшает производительность обмена данными. Единственным способом уменьшения фрагментации файловой системы является создание полной резервной копии на другом носителе (или в другой файловой системе) и Затем СС ВОССТанОВЛСНИИ. При этом запись файлов будет производиться последовательно без фрагментации.
• При этом между началом файла и началом записанных данных образуется дыра -- незаполненная область. При чтении этой области процесс получит обнуленные байты. Поскольку логические блоки, соответствующие дыре, не содержат данные, не имеет смысла размещать для них дисковые блоки. В этом случае соответствующие элементы массива адресов inode содержат нулевой указатель. Когда процесс производит чтение такого блока, ядро возвращает последовательность нулей. Дисковые блоки размещаются только при записи в соответствующие логические блоки файла2.
• Имена файлов
• Как мы уже видели, ни метаданные, ни тем более блоки хранения данных, не содержат имени файла. Имя файла хранится в файлах специального типа -- каталогах. Такой подход позволяет любому файлу, т. е. фактическим данным, иметь теоретически неограниченное число имен (названий), в файловой системе. При этом несколько имен файлов будут соответствовать одним и тем же метаданным и данным и являться жесткими связями.
• Каталог файловой системы s5fs представляет собой таблицу, каждый элемент которой имеет фиксированный размер в 16 байтов: 2 байта хранят номер индексного дескриптора файла, а 14 байтов -- его имя. Это накладывает ограничение на число inode, которое не может превышать 65 535. Также ограничена и длина имени файла: его максимальный размер -- 14 символов. Структура каталога приведена на рис. 3.
• Первые два элемента каталога адресуют сам каталог (текущий каталог) под именем "." и родительский каталог под именем "..".
• При удалении имени файла из каталога (например, с помощью команды rm(lj), номер inode соответствующего элемента устанавливается равным 0. Ядро обычно не удаляет такие свободные элементы, поэтому размер каталога не уменьшается даже при удалении файлов. Это является потенциальной проблемой для каталогов, в которые временно было помещено большое количество файлов. После удаления большинства из них размер каталога останется достаточно большим, поскольку записи удаленных файлов будут по-прежнему существовать.
• Отсутствие размещенных дисковых блоков для части файла может привести к нежелательным результатам. Например, операция записи в "дыру" может закончиться неудачей из-за нехватки дискового пространства. При копировании файла с дырой, его копия будет занимать больше фактического места на диске, чем оригинал. Это связано с тем, что при копировании производится чтение содержимого оригинала, а затем -- запись в другой файл. Это, в частности может привести к тому, что резервная копия файловой системы не сможет быть обратно распакована, поскольку вместо неразмещенных блоков будет хранить законные нулевые байты и, соответственно, занимать больше места.
• Иллюстрацию этого явления в SCO UNIX можно привести, применив команду hd(lM), обеспечивающую вывод неинтерпретированного содержимого файла (шестнадцатеричный дамп).
• Можно заметить, что имен файлов, расположенных во второй части вывода команды hd(lM) на самом деле не существует -- об этом свидетельствуют нулевые значения номеров inode, это же подтверждает вывод команды ls(l):
• $
• -а
• is
• .newsrc
• bin
• dead.letter
• News mai
• Рис. 3. Массив индексных дескрипторов Mist. Каталог файловой системы s5fs
• 1.5. Недостатки и ограничения
• Файловая система s5fs привлекательна благодаря своей простоте. Однако обратной стороной медали является низкая надежность и производительность.
• С точки зрения надежности слабым местом этой файловой системы является суперблок. Суперблок несет основную информацию о файловой системе в целом, и при его повреждении файловая система не может использоваться. Поскольку в файловой системе s5fs суперблок хранится в единственном варианте, вероятность возникновения ошибок достаточно велика.
• Относительно низкая производительность связана с размещением компонентов файловой системы на диске. Метаданные файлов располагаются в начале файловой системы, а далее следуют блоки хранения данных. При работе с файлом, происходит обращение как к его метаданным, так и к дисковым блокам, содержащим его данные. Поскольку эти структуры данных могут быть значительно разнесены в дисковом пространстве, необходимость постоянного перемещения головки диска увеличивает время доступа и, как следствие, уменьшает производительность файловой системы в целом. К этому же эффекту приводит фрагментация файловой системы, поскольку отдельные блоки файла оказываются разбросанными по всему разделу диска.
• Использование дискового пространства также не оптимально. Для увеличения производительности файловой системы более предпочтительным является использование блоков больших размеров. Это позволяет считывать большее количество данных за одну операцию ввода/вывода. Так, например, в UNIX SVR2 размер блока составлял 512 байтов, а в SVR3 -- уже 1024 байтов. Однако поскольку блок может использоваться только одним файлом, увеличение размера блока приводит к увеличению неиспользуемого дискового пространства за счет частичного заполнения последнего блока файла. В среднем для каждого файла теряется половина блока.
• Массив inode имеет фиксированный размер, задаваемый при создании файловой системы. Этот размер накладывает ограничение на максимальное число файлов, которые могут существовать в файловой системе. Расположение границы между метаданными файлов и их данными (блоками хранения данных) может оказаться неоптимальным, приводящим либо к нехватке inode, если файловая система хранит файлы небольшого размера, либо к нехватке дисковых блоков для хранения файлов большого размера. Поскольку динамически изменить эту границу невозможно, всегда останется неиспользованное дисковое пространство либо в массиве inode, либо в блоках хранения данных.
• Наконец, ограничения, накладываемые на длину имени файла (14 символов) и общее максимальное число inode (65 535), также являются слишком жесткими.
• Все эти недостатки привели к разработке новой архитектуры файловой системы, которая появилась в версии 4.2BSD UNIX под названием Berkeley Fast File System, или FSS.
• 1.6 Файловая система BSD UNIX
• В версии 4.3BSD UNIX были внесены существенные улучшения в архитектуру файловой системы, повышающие как ее производительность, так и надежность. Новая файловая система получила название Berkeley Fast File System (FFS).
• Файловая система FFS, обладая полной функциональностью системы s5fs, использует те же структуры данных ядра. Основные изменения затронули расположение файловой системы на диске, дисковые структуры данных и алгоритмы размещения свободных блоков.
• Как и в случае файловой системы s5fs, суперблок содержит общее описание файловой системы и располагается в начале раздела. Однако в суперблоке не хранятся данные о свободном пространстве файловой системы, такие как массив свободных блоков и mode. Поэтому данные суперблока остаются неизменными на протяжении всего времени существования файловой системы. Поскольку данные суперблока жизненно важны для работы всей файловой системы, он дублируется для повышения надежности.
• Рис. 4. Структура файловой системы FFS
• Организация файловой системы предусматривает логическое деление дискового раздела на одну или несколько групп цилиндров (cylinder group). Группа цилиндров представляет собой несколько последовательных дисковых цилиндров. Каждая группа цилиндров содержит управляющую информацию, включающую резервную копию суперблока, массив inode, данные о свободных блоках и итоговую информацию об использовании дисковых блоков в группе (рис. 4).
• Для каждой группы цилиндров при создании файловой системы выделяется место под определенное количество inode. При этом обычно на каждые 2 Кбайт блоков хранения данных создается один inode. Поскольку размеры группы цилиндров и массива inode фиксированы, в файловой системе BSD UNIX присутствуют ограничения, аналогичные s5fs.
• Идея такой структуры файловой системы заключается в создании кластеров inode, распределенных по всему разделу, вместо того, чтобы группировать все inode в начале. Тем самым уменьшается время доступа к данным конкретного файла, поскольку блоки данных располагаются ближе к адресующем их inode. Такой подход также повышает надежность файловой системы, уменьшая вероятность потери всех индексных дескрипторов в результате сбоя.
• Управляющая информация располагается с различным смещением от начала группы цилиндров. В противном случае, например, при размещении в начале группы цилиндров, информация всех групп оказалась бы физически расположенной на одной пластине диска и могла бы быть уничтожена при выходе из строя этой пластины. Это смещение выбирается равным одному сектору относительно предыдущей группы, таким образом для соседних групп управляющая информация начинается на различных пластинах диска. В этом случае потеря одного сектора, цилиндра или пластины не приведет к потере всех копий суперблоков.
• Производительность файловой системы существенным образом зависит от размера блока хранения данных. Чем больше размер блока, тем большее количество данных может быть прочитано без поиска и перемещения дисковой головки. Файловая система FFS поддерживает размер блока до 64 Кбайт. Проблема заключается в том, что типичная файловая система UNIX состоит из значительного числа файлов небольшого размера. Это приводит к тому, что частично занятые блоки используются неэффективно, что может привести к потере до 60% полезной емкости диска.
• Этот недостаток был преодолен с помощью возможности фрагментации блока. Каждый блок может быть разбит на два, четыре или восемь фрагментов. В то время как блок является единицей передачи данных в операциях ввода/вывода, фрагмент определяет адресуемую единицу хранения данных на диске. Таким образом, был найден компромисс между производительностью ввода/вывода и эффективностью хранения данных. Размер фрагмента задается при создании файловой системы, его максимальное значение определяется размером блока (0,5 размера блока), а минимальный -- физическими ограничениями дискового устройства, а именно: минимальной единицей адресации диска -- сектором.
• Информация о свободном пространстве в группе хранится не в виде списка свободных блоков, а в виде битовой карты блоков. Карта блоков, связанная с определенной группой цилиндров, описывает свободное пространство в фрагментах, для определения того, свободен данный блок или нет, ядро анализирует биты фрагментов, составляющих блок.
• Существенные изменения затронули алгоритмы размещения свободных блоков и inode, влияющие на расположение файлов на диске. В файловой системе s5fs используются весьма примитивные правила размещения. Свободные блоки и inode просто выбираются из конца соответствующего списка, что со временем приводит, как уже обсуждалось, к значительному разбросу данных файла по разделу диска.
• В отличие от s5fs, файловая система FFS при размещении блоков использует стратегию, направленную на увеличение производительности. Некоторые из принципов приведены ниже:
• 1. Файл по возможности размещается в блоках хранения данных, принадлежащих одной группе цилиндров, где расположены его метаданные. Поскольку многие операции файловой системы включают работу, связанную как с метаданными, так и с данными файла, это правило уменьшает время совершения таких операций.
• 2. Все файлы каталога по возможности размещаются в одной группе цилиндров. Поскольку многие команды работают с несколькими файлами одного и того же каталога, данный подход увеличивает скорость последовательного доступа к этим файлам.
• 3. Каждый новый каталог по возможности помещается в группу цилиндров, отличную от группы родительского каталога. Таким образом достигается равномерное распределение данных по диску.
• 4. Последовательные блоки размещаются исходя из оптимизации физического доступа. Дело в том, что существует определенный промежуток времени между моментом завершения чтения блока и началом чтения следующего. За это время диск успеет совершить оборот на некоторый угол. Таким образом, следующий блок должен по возможности располагаться с пропуском нескольких секторов. В этом случае при чтении последовательных блоков не потребуется совершать "холостые" обороты диска.
• Таким образом, правила размещения свободных блоков, с одной стороны, направлены на уменьшение времени перемещения головки диска, т. е. на локализацию данных в одной группе цилиндров, а с другой -- на равномерное распределение данных по диску. От разумного баланса между этими двумя механизмами зависит, в конечном итоге, производительность файловой системы. Например, в предельном варианте, когда все данные локализованы в одной большой группе цилиндров, мы получаем типичную файловую систему s5fs.
• Описанная архитектура является весьма эффективной с точки зрения надежности и производительности. К сожалению, эти параметры файловой системы FSS начинают значительно ухудшаться по мере уменьшения свободного места. В этом случае системе не удается следовать вышеприведенным правилам и размещение блоков далеко от оптимального. Практика показывает, что FSS имеет удовлетворительные характеристики при наличии более 10% свободного места.
• Каталоги
• Структура каталога файловой системы FFS была изменена для поддержки длинных имен файлов (до 255 символов). Вместо записей фиксированной длины запись каталога FFS представлена структурой, имеющей следующие поля:
• d ino Номер inode (индекс в массив ilist)
• d recien Длина записи
• dnamlen Длина имени файла
• d__name [ ] Имя файла
• Имя файла имеет переменную длину, дополненную нулями до 4-байтной границы. При удалении имени файла принадлежавшая ему запись присоединяется к предыдущей, и значение поля d reclen увеличивается на соответствующую величину. Удаление первой записи выражается в присвоении нулевого значения полю d_ino. Структура каталога файловой системы FFS приведена на рис. 5.
• Рис. 5. Каталог файловой системы FFS
• 1.7 Виртуальная файловая система
• Как было показано, различные типы файловых систем существенно отличаются по внутренней архитектуре. В то же время современные версии UNIX обеспечивают одновременную работу с несколькими типами файловых систем. Среди них можно выделить локальные файловые системы различной архитектуры, удаленные и даже отличные от файловой системы UNIX, например DOS. Такое сосуществование обеспечивается путем разделения каждой файловой системы на зависимый и независимый от реализации уровни, последний из которых является общим и представляет для остальных подсистем ядра некоторую абстрактную файловую систему. Независимый уровень также называется виртуальной файловой системой (рис. 6). При этом дополнительные файловые системы различных типов могут быть встроены в ядро UNIX подобно тому, как это происходит с драйверами устройств.
• Рис. 6. Архитектура виртуальной файловой системы
• 1.8 Виртуальные индексные дескрипторы
• Дисковый файл обычно имеет связанную с ним структуру данных, называемую метаданными или inode, где хранятся основные характеристики данного файла и с помощью которой обеспечивается доступ к его данным. Одним из исключений из этого правила является файловая система DOS, в которой структуры файла и его метаданных существенно отличаются от принятых в UNIX. Тем не менее, виртуальная файловая система основана на представлении метаданных файла в виде, сходном с традиционной семантикой UNIX. Интерфейсом работы с файлами является vnode (от virtual inode -- виртуальный индексный дескриптор).
• Первоначально этот интерфейс был разработан в 1984 году фирмой Sun Microsystems для обеспечения требуемой унификации работы с файловыми системами различных типов, в частности, с NFS и ufs (FFS). Сегодня виртуальная файловая система является стандартом в SVR4, хотя ряд других версий UNIX также реализуют подобную архитектуру (например, независимая файловая система SCO UNIX).
• Метаданные всех активных файлов (файлов, на которые ссылаются один или более процессов) представлены в памяти в виде in-core inode, в качестве которых в виртуальной файловой системе выступают vnode. Структура данных vnode одинакова для всех файлов, независимо от типа реальной файловой системы, где фактически располагается файл. Данные vnode содержат информацию, необходимую для работы виртуальной файловой системы, а также неизменные характеристики файла, например, такие как тип файла.
• Основные поля vnode приведены в табл. 1.
• Таблица 1. Поля vnode

Поле
u short	vf lag
u short	v count
struct filock	* v filocks
struct vfs	lv vfsmountedhere
struct vfs	*v_vfsp
enum vtype	v_type
caddr t	v data
struct vnodeop;	з *v op

• Описание
• Флаги vnode
• Число ссылок на vnode
• Блокировки файла
• Указатель на подключенную файловую систему, если vnode является точкой монтирования
• Тип vnode: обычный файл, каталог, специальный файл устройства, символическая связь, сокет
• 1.9 Операции vnode
• Каждый vnode содержит число ссылок vcount, которое увеличивается при открытии процессом файла и уменьшается при его закрытии. Когда число ссылок становится равным нулю, вызывается операция vn inactive (), которая сообщает реальной файловой системе, что на vnode никто больше не ссылается. После этого файловая система может освободить vnode (и, например, соответствующий ему inode) или поместить его в кэш для дальнейшего использования.
• Поле v_vfsp указывает на файловую систему (структуру vfs, о которой мы поговорим в следующем разделе), в которой расположен файл, адресованный данным vnode. Если vnode является точкой монтирования, то поле v vfsmountedhere указывает на подключенную файловую систему, "перекрывающую" данный vnode.
• Поле v_data указывает на данные, относящиеся к конкретной реализации реальной файловой системы. Например, для дисковой файловой системы ufs, vdata указывает на запись в таблице in-core inode.
• Набор операций над vnode указан полем v_op. В терминах объектно-ориентированного программирования этот набор представляет собой виртуальные методы класса vnode. Он является своего рода шлюзом к реальной файловой системе, позволяя предоставить общий интерфейс виртуальной файловой системы и в то же время обеспечить специфические реализации функций работы с файлами, необходимые для различных типов файловых систем. Обычно операции такого типа характерны для специальных файлов устройств.
• close) о Закрыть vnode.
• read) () Чтение данных файла, адресованного vnode.
• write) о Запись в файл, адресованный vnode.
• iocti) о Задание управляющей команды.
• getaddr) о Получить атрибуты vnode: тип vnode, права доступа, владелец-пользователь, владелец-группа, идентификатор файловой системы, номер inode, число связей, размер файла, оптимальный размер блока для операций ввода/вывода, время последнего доступа, время последней модификации, время последней модификации vnode, число занимаемых блоков.
• Int (*vn setaddr)()
• Установить атрибуты vnode. Могут быть изменены UID, GID, размер файла и времена доступа и модификации.
• { *vn
• Int (*vn_lookup)() <*vn
• Проверить права доступа к файлу, адресованному vnode. При этом производится отображение между атрибутами доступа файлов UNIX и атрибутами реальной файловой системы (например, DOS).
• Lilt Произвести трансляцию имени файла в соответстсвующий ему vnode.
• Int create) о Создать новый файл и соответствующий ему vnode.
• Взаимосвязь между независимыми дескрипторами (vnode) и зависимыми от реализации метаданными файла показана на рис. 7.
• Рис. 7. Метаданные файла виртуальной файловой системы
• 1.10 Монтирование файловой системы
• Прежде чем может состояться работа с файлами, соответствующая файловая система должна быть встроена в существующее иерархическое дерево.
• Только после этого ядро сможет выполнять файловые операции, такие как создание, открытие, чтение или запись в файл. Эта операция встраивания получила название подключения или монтирования файловой системы.
• Каждая подключенная файловая система представлена на независимом уровне в виде структуры vfs, аналоге записи таблицы монтирования дисковой файловой системы. Структуры vfs всех подключенных файловых систем организованы в виде односвязного списка, в совокупности обеспечивая информацию, необходимую для обслуживания всего иерархического дерева, а также информацию о реальной файловой системе, которые не изменяются на протяжении работы. Первой записью списка всегда является корневая файловая система.
• Поле vfs data содержит указатель на данные реальной файловой системы. Например, для дисковой файловой системы s5fs, это поле указывает на суперблок, размещенный в памяти.
• Поле vfsop указывает на операции файловой системы, которые в терминах объектно-ориентированного подхода могут быть названы виртуальными методами объекта vfs. Поскольку они существенным образом зависят от архитектуры и конкретной реализации, поля vf s_op заполняются указателями на соответствующие функции реальной файловой системы при ее монтировании.
• Для инициализации и монтирования реальной файловой системы UNIX хранит коммутатор файловых систем (File System Switch), адресующий процедурный интерфейс для каждого типа файловой системы, поддерживаемой ядром. UNIX System V для этого использует глобальную таблицу, каждый элемент которой соответствует определенному типу реальной файловой системы, например s5fs, ufs или nfs. Взаимодействие структур виртуальной файловой системы показано на рис. 8.
• Монтирование файловой системы производится системным вызовом mount(2). В качестве аргументов передаются тип монтируемой файловой системы, имя каталога, к которому подключается файловая система (точка монтирования), флаги (например, доступ к файловой системе только для чтения) и дополнительные данные, конкретный вид и содержимое которых зависят от реализации реальной файловой системы. При этом производится поиск vnode, соответствующего файлу -- точке монтирования (операция lookup () или namei () трансляции имени), и проверяется, что файл является каталогом и не используется в настоящее время для монтирования других файловых систем.
• Затем происходит поиск элемента коммутатора файловых систем vf ssw, соответствующего типу монтируемой файловой системы. Если такой элемент найден, вызывается операция инициализации, адресованная полем vsw_init (). При этом выполняется размещение специфических для данного типа файловой системы данных, после чего ядро размещает структуру vfs и помещает ее в связанный список подключенных файловых систем, как это показано на рис. 8. Поле vfs_vnodecovered указывает на vnode точки монтирования. Это поле устанавливается нулевым для корневой (root) файловой системы, элемент vfs которой всегда расположен первым в списке подключенных файловых систем. Поле vfs_op адресует вектор операций, определенный для данного типа файловой системы. Наконец, указатель на данный элемент vfs сохраняется в поле v_vfsmountecihere виртуального индексного дескриптора каталога -- точки монтирования.

• Рис. 8. Структуры данных виртуальной файловой системы
• После этого вызывается операция vfs mount (), соответствующая данному типу файловой системы. Конкретные действия определяются реализацией файловой системы и могут существенно различаться. Например, операция монтирования локальной файловой системы ufs предусматривает считывание в память метаданных системы, таких как суперблок, в то время как монтирование удаленной NFS файловой системы включает передачу сетевого запроса файловому серверу. Однако монтирование предусматривает выполнение и ряда общих операций, включающих:
• О проверку соответствующих прав на выполнение монтирования;
• - размещение и инициализацию специфических для файловой системы данного типа данных, сохранение адреса этих данных в поле vfs data элемента vfs;
• - размещение vnode для корневого каталога подключаемой файловой системы, доступ к которому осуществляется с помощью операции vfs_root().
• После подключения файловая система может быть адресована по имени точки монтирования. В частности, при отключении файловой системы с помощью системного вызова umount(2), в качестве аргумента ему передается имя точки монтирования. Адресация с помощью специального файла устройства, как это происходило раньше, нарушает унифицированный вид виртуальной файловой системы, так как некоторые типы вообще не имеют такого устройства (например, NFS).
• Определение корневого vnode для подключенной файловой системы производится с помощью операции vfs_root (). Заметим, что в некоторых реализациях независимой файловой системы (например, в SCO UNIX, хотя там используется другая терминология) одно из полей записи таблицы монтирования явно указывало на корневой vnode. Подход, предложенный фирмой Sun Microsystems, позволяет не хранить корневой vnode постоянно, размещая его только при необходимости работы с файловой системой. Это минимизирует ресурсы, занимаемые подключенными файловыми системами, которые продолжительное время не используются.
• На рис. 9 приведен вид логического файлового дерева до и после монтирования файловой системы А к каталогу /usr/local. На рис. 10 приведен вид виртуальной файловой системы после этой операции монтирования.
• Мы распечатали список подключенных файловых систем (команда mount(lM))и элементы vfs таблицы монтирования. Рассмотрим подробнее vnode точки монтирования файловой системы раздела /dev/dsk/cOtOdOsO.
• vnode f5c29adO
• VCNT VFSMNTED VFSP STREAMP VTYPE RDEV VDATA VFILOCKS VFLAG 2 f5c25c60 f0286570 0 d - f5c29ac8 0
• Удостоверимся, что поле v_vfsmountedhere (VFSMNTED) адресует элемент vfs подключенной файловой системы, а поле vfsp (VFSP) указывает на элемент корневой файловой системы.
• vfs f5c25c60

• Рис. 9. Монтирование файловой системы А к корневой файловой системе

• Рис. 10. Схема монтирования файловых систем различных типов
• Архитектура виртуальной файловой системы 303
• Полученная информация показывает, что запись таблицы inode ufs адресует дисковый индексный дескриптор с номером 7552 (INUMB). Для того чтобы узнать имя файла, используем команду ncheck(lM):
• > 'ncheck -i 7552
• /dev/dsk/c0t3d0s0: 7552 /usr/local
• 1.11 Трансляция имен
• Прикладные процессы, запрашивая услуги файловой системы, обычно имеют дело с именем файла или файловым дескриптором, полученным в результате определенных системных вызовов. Однако ядро системы для обеспечения работы с файлами использует не имена, а индексные дескрипторы. Таким образом, необходима трансляция имени файла, передаваемого, например, в качестве аргумента системному вызову ореп(2), в номер соответствующего vnode.
• Говоря формально, полное имя файла представляет собой последовательность слов, разделенных символом '/'. Каждый компонент имени, кроме последнего, является именем каталога. Последний компонент определяет собственно имя файла. При этом полное имя может быть абсолютным или относительным. Если полное имя начинается с символа '/', представляющего корневой каталог общего логического дерева файловой системы, то оно является абсолютным, однозначно определяющим файл из любого места файловой системы. В противном случае, имя является относительным и адресует файл относительно текущего каталога. Примером относительного имени может служить include/sys/user.h, а абсолютное имя этого файла -- /usr/include/sys/user.h. Как следует из этих рассуждений, два каталога играют ключевую роль при трансляции имени: корневой каталог и текущий каталог. Каждый процесс адресует эти каталоги двумя полями структуры uarea:
• struct vnode *u_cdir Указатель на vnode текущего каталога
• struct vnode +u_rdir Указатель на vnode корневого каталога
• В зависимости от имени файла трансляция начинается с vnode, адресованного либо полем u_cdir, либо urdir. Трансляция имени осуществляется покомпонентно, при этом для vnode текущего каталога вызывается соответствующая ему операция vnlookup (), в качестве аргумента которой передается имя следующего компонента. В результате операции возвращается vnode, соответствующий искомому компоненту.
• Если для vnode каталога установлен указатель vn__vfsmountedhere, то данный каталог является точкой монтирования. Если имя файла требует дальнейшего спуска по дереву файловой системы (т. е. пересечения точки монтирования), то операция vn_lookup() следует указателю vn_vfsmountedhere для перехода в подключенную файловую систему и вызывает для нее операцию vfsroot {) для получения ее корневого vnode. Трансляция имени затем продолжается с этого места.
• Пересечение границы файловых систем возможно и при восхождении по дереву, например, если имя файла задано указанием родительского каталога --../../myfile.txt. Если при движении в этом направлении по пути встречается корневой vnode подключенной файловой системы (установлен флаг VROOT в поле v_f lag), то операция vn_lookup () следует указателю vfsvnodecovered, расположенному в записи vfs этой файловой системы. При этом происходит пересечение границы файловых систем, и дальнейшая трансляция продолжается с точки монтирования.
• Если искомый файл является символической связью, и системный вызов, от имени которого происходит трансляция имени, "следует" символической связи, операция vn_lookup() вызывает vnreadlink () для получения имени целевого файла. Если оно является абсолютным (т. е. начинается с "/"), то трансляция начинается с vnode корневого каталога, адресованного полем urdir области u-area.
• Процесс трансляции имени продолжается, пока не просмотрены все компоненты имени или не обнаружена ошибка (например, отсутствие прав доступа). В случае удачного завершения возвращается vnode искомого файла.
• 1.12 Доступ к файловой системе
• Как было показано в главе 2, процесс совершает операции с файлами, адресуя их при помощи файловых дескрипторов -- целых чисел, имеющих локальное для процесса значение. Это значит, что файловый дескриптор одного процесса может адресовать совершенно другой файл, нежели файловый дескриптор с таким же номером, используемый другим процессом. Процесс получает файловый дескриптор с помощью ряда системных вызовов, например, ореп(2)или creat(2)), выполняющих операцию трансляции имени, в результате которой выделяемый файловый дескриптор адресует определенный inode (или vnode) и, соответственно, файл файловой системы.
• На рис. 11 показаны основные структуры ядра, необходимые для доступа процесса к файлу.
• Рис. 11. Внутренние структуры доступа к файлу
• Файловый дескриптор, используемый для доступа процесса к файлу, является индексом таблицы файловых дескрипторов (file descriptor table). Каждый процесс имеет собственную таблицу файловых дескрипторов, которая расположена в его u-area. На рис. 12 показаны два процесса, каждый из которых использует собственную таблицу файловых дескрипторов.
• Каждая активная запись этой таблицы, представляющая открытый файл, адресует запись системной файловой таблицы (system file table), в которой хранятся такие параметры, как режим доступа к файлу (запись, чтение, добавление и т. д.), текущее смещение в файле (файловый указатель), а также указатель па vnode этого файла. Системная файловая таблица одна и совместно используется всеми процессами.
• Как следует из рис. 12, несколько записей системной файловой таблицы могут адресовать один и тот же файл, который представлен единственной записью в таблице vnode.
• 1.13 Файловые дескрипторы
• Файловый дескриптор представляет собой неотрицательное целое число, возвращаемое системными вызовами, такими как creat(2), open(2) или pipe(2). После получения файлового дескриптора процесс может использовать его для дальнейшей работы с файлом, например с помощью системных вызовов read(2), whte(2), close(2) или fcntl(2).
• Ядро обеспечивает работу процесса с файлами, используя различные структуры данных, часть из которых расположена в u-area процесса. Напомним, что эта область описывается структурой user. Файловый дескриптор связан с этими двумя полями и, таким образом, обеспечивает доступ к соответствующему элементу файловой таблицы (структуре данных file).
• В настоящее время в качестве единственного флага файлового дескриптора определен флаг FD_CLOEXEC. Если этот флаг установлен, то производится закрытие файлового дескриптора (аналогично явному вызову close(2)) при выполнении процессом системного вызова ехес(2)). При этом для запущенной программы не происходит наследования файлового дескриптора и доступа к файлу.
• Более старые версии UNIX используют статическую таблицу дескрипторов, которая целиком хранится в u-area. Номер дескриптора является индексом этой таблицы. Таким образом, размер таблицы, которая обычно содержит 64 элемента, накладывает ограничение на число одновременно открытых процессом файлов. В современных версиях таблица размещается динамически и может увеличиваться при необходимости. Например, для текущего командного интерпретатора мы получим следующую информацию:
• # crash
• dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout
• > proc #8591
• PROC TABLE SIZE = 1498
• SLOT ST PID PPID PGID SID UID PRI NAME FLAGS 121 s 8591 8589 8591 8591 286 48 bash load jctl
• > user 121
• PER PROCESS USER AREA FOR PROCESS 121 PROCESS MISC:
• command: bash, psargs: -bash
• start: PO Mon 24 18:11:31 1997
• mem: lebc, type: exec
• vnode of current directory: f5b95e40 OPEN FILES, POFILE FLAGS, AND THREAD REFCNT:
• [0] : F Oxf62b6030, 0, 0 [1] : F Oxf62b6030, О, О [2] : F Oxf62b6030, О, О cinask: 0022 RESOURCE LIMITS:
• cpu time: unlimited/unlimited
• file size: unlimited/unlimited
• swap size: 2147479552/2147479552
• stack size: 8388608/2147479552
• coredump size: unlimited/unlimited
• file descriptors: 64/1024
• address space: unlimited/unlimited SIGNAL DISPOSITION:
• 1.14 Файловая таблица
• Поля файлового дескриптора u_ofile и u_pofile содержат начальную информацию, необходимую для доступа процесса к данным файла. Дополнительная информация находится в системной файловой таблице и таблице индексных дескрипторов. Для обеспечения доступа процесса к данным файла ядро должно полностью создать цепочку от файлового дескриптора до vnode и, соответственно, до блоков хранения данных, как показано на рис. 12.
• Каждый элемент файловой таблицы содержит информацию, необходимую для управления работой с файлом. Если несколько процессов открывают один и тот же файл, каждый из них получает собственный элемент файловой таблицы, хотя все они будут работать с одним и тем же файлом. Важнейшие поля элемента файловой таблицы приведены ниже:
• Поле Описание f_flag Флаги, указанные при открытии файла (системные вызовы ореп(2), creat(2)). Каждая операция с файлом проверяется на допустимость согласно указанным режимам. Другими словами, если процесс открыл файл только для чтения (флаг FREAD), ему будет отказано в операции записи, даже если он имеет на это необходимые права доступа.
• FREAD Файл открыт только для чтения. То же, что и O_RDONLY при открытии файла.
• fwrite Файл открыт только на запись. То же, что и o_wronly при открытии файла.
• FAPPEND Режим добавления. Перед началом операции записи файловый указатель будет установлен в конец файла. То же, что и O_APPEND при открытии файла.
• fnonblock, Возврат без блокирования. Системный вызов не будет ожидать за- fndelay вершения операции. То же, что и o_nonblock или o_ndelay при открытии файла.
• FSYNC Обеспечить синхронизацию с соответствующими дисковыми структурами для метаданных и данных файла при совершении операции записи. То же, что и oSYNC при открытии файла.
• FDSYNC Обеспечить синхронизацию с соответствующими дисковыми структурами только для данных файла при совершении операции записи. То же, что и ojdsync при открытии файла.
• FRSYNC Совместно с флагами FCYNC и FDSYNC определяет процесс синхронизации для соответствующих компонентов файла при операции чтения.
• f_count Число файловых дескрипторов, адресующих данный элемент файловой таблицы. Один и тот же элемент файловой таблицы может совместно использоваться при дублировании дескрипторов с помощью системного вызова dup(2) или в результате fork(2).
• f vnode Указатель на виртуальный индексный дескриптор файла.
• fof f set Текущее смещение в файле. Начиная с этого места будет произведена следующая операция чтения или записи.
• Для иллюстрации обсуждения продолжим работу с утилитой crash(lM). С помощью команды user в предыдущем разделе были получены адреса элементов файловой таблицы для стандартного ввода (fd=0), вывода (fd=l) и вывода сообщений об ошибках (fd=2). Заметим, что все они указывают на один и тот же элемент. С помощью команды file исследуем его содержимое:
• > file Oxf62b6030
• ADDRESS RCNT TYPE/ADDR OFFSET f62b6030 9 SPEC/f5e91clc 15834
• > vnode f5e91clc
• VCNT VFSMNTED VFSP STREAMP VTYPE 2 0 f0286570 f5c6b2aO с
• FLAGS read write
• RDEV VDATA VFILOCKS VFLAG
• 24,26 f5e91cl8 0
• Поскольку это специальный файл устройства (об этом свидетельствует поле TYPE элемента файловой таблицы), поле v__data (VDATA) vnode указывает не на inode файловой системы ufs, а на snode -- индексный дескриптор логической файловой системы specfs, обслуживающей специальные файлы устройств. Более подробно этот интерфейс будет рассматриваться в следующей главе. Таким образом, для продолжения путешествия по структурам данных ядра, следует обратиться к snode, адрес которого указан в поле VDATA.
• В результате мы определили имя специального файла устройства (в данном случае -- это псевдотерминал), на которое производится ввод и вывод командного интерпретатора.
• 1.15 Блокирование доступа к файлу
• Традиционно архитектура файловой подсистемы UNIX разрешает нескольким процессам одновременный доступ к файлу для чтения и записи. Хотя операции записи и чтения, осуществляемые с помощью системных вызовов read(2)или write(2), являются атомарными, в UNIX по умолчанию отсутствует синхронизация между отдельными вызовами. Другими словами, между двумя последовательными вызовами read(2) одного процесса другой процесс может модифицировать данные файла. Это, в частности, может привести к несогласованным операциям с файлом, и как следствие, ченная специально для управления блокированием. При этом перед фактической файловой операцией (чтения или записи) процесс устанавливает блокирование соответствующего типа (для чтения или для записи). Если блокирование завершилось успешно, это означает, что требуемая файловая операция не создаст конфликта или нарушения целостности данных, например, при одновременной записи в файл несколькими процессами.
• По умолчанию блокирование является рекомендательным (advisory lock). Это означает, что кооперативно работающие процессы могут руководствоваться созданными блокировками, однако ядро не запрещает чтение или запись в заблокированный участок файла. При работе с рекомендательными блокировками процесс должен явно проверять их наличие с помощью тех же функций fcntl(2) и lockf(3C).
...