Каждый жесткий диск состоит из одной или нескольких логических частей, называемых разделами (partitions). Расположение и размер раздела определяются при форматировании диска. В UNIX разделы выступают в качестве независимых устройств, доступ к которым осуществляется как к различным носителям данных.

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

Файловая система s5fs занимает раздел диска и состоит из трех основных компонентов, как показано на рис. 4.1.

Рис. 4.1. Структура файловой системы s5fs

□ Суперблок (superblocк). Содержит общую информацию о файловой системе, например, об ее архитектуре, общем числе блоков и индексных дескрипторов, или метаданных (inode).

□ Массив индексных дескрипторов (ilist). Содержит метаданные всех файлов файловой системы. Индексный дескриптор содержит статусную информацию о файле и указывает на расположение данных этого файла. Ядро обращается к inode по индексу в массиве ilist. Один inode является корневым (root) inode файловой системы, через него обеспечивается доступ к структуре каталогов и файлов после монтирования файловой системы. Размер массива ilist является фиксированным и задается при создании файловой системы. Таким образом, файловая система s5fs имеет ограничение по числу файлов, которые могут храниться в ней, независимо от размера этих файлов.

□ Блоки хранения данных. Данные обычных файлов и каталогов хранятся в блоках. Обработка файла осуществляется через inode, содержащего ссылки на блоки данных. Блоки хранения данных занимают большую часть дискового раздела, и их число определяет максимальный суммарный объем файлов данной файловой системы. Размер блока кратен 512 байтам, например файловая система S51K SCO UNIX использует размер блока в 1 Кбайт (отсюда и название).

Рассмотрим подробнее каждый из перечисленных компонентов.

 

Суперблок

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

Суперблок содержит следующую информацию:

□ Тип файловой системы (s_type)

□ Размер файловой системы в логических блоках, включая сам суперблок, ilist и блоки хранения данных (s_fsize)

□ Размер массива индексных дескрипторов (s_isize)

□ Число свободных блоков, доступных для размещения (s_tfree)

□ Число свободных inode, доступных для размещения (s_tinode)

□ Флаги (флаг модификации s_fmod, флаг режима монтирования s_fronly)

□ Размер логического блока (512, 1024, 2048)

□ Список номеров свободных inode

□ Список адресов свободных блоков

Поскольку число свободных inode и блоков хранения данных может быть значительным, хранение двух последних списков целиком в суперблоке непрактично. Например, для индексных дескрипторов хранится только часть списка. Когда число свободных inode в этом списке приближается к 0, ядро просматривает ilist и вновь формирует список свободных inode. Для этого ядро анализирует поле di_mode индексного дескриптора, которое равно 0 у свободных inode.

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

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

 

Индексные дескрипторы

Индексный дескриптор, или inode, содержит информацию о файле, необходимую для обработки данных, т.е. метаданные файла. Каждый файл ассоциирован с одним inode, хотя может иметь несколько имен в файловой системе, каждое из которых указывает на один и тот же inode.

Индексный дескриптор не содержит:

□ имени файла, которое содержится в блоках хранения данных каталога;

□ содержимого файла, которое размещено в блоках хранения данных.

При открытии файла ядро помещает копию дискового inode в память в таблицу in-core inode, которая содержит несколько дополнительных полей. Структура дискового inode (struct dinode) приведена на рис. 4.2. Основные поля дискового inode следующие:

Рис. 4.2. Структура дискового inode

Поле 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 должен хранить физические адреса всех блоков, принадлежащих данному файлу. В индексном дескрипторе эта информация хранится в виде массива, каждый элемент которого содержит физический адрес дискового блока, а индексом массива является номер логического блока файла. Массив имеет фиксированный размер и состоит из 13 элементов. При этом первые 10 элементов адресуют непосредственно блоки хранения данных файла. Одиннадцатый элемент адресует блок, в свою очередь содержащий адреса блоков хранения данных. Двенадцатый элемент указывает на дисковый блок, также хранящий адреса блоков, каждый из который адресует блок хранения данных файла. И, наконец, тринадцатый элемент используется для тройной косвенной адресации, когда для нахождения адреса блока хранения данных файла используются три дополнительных блока.

Такой подход позволяет при относительно небольшом фиксированном размере индексного дескриптора поддерживать работу с файлами, размер которых может изменяться от нескольких байтов до десятка мегабайтов. Для относительно небольших файлов (до 10 Кбайт при размере блока 1024 байтов) используется прямая индексация, обеспечивающая максимальную производительность. Для файлов, размер которых не превышает 266 Кбайт (10 Кбайт + 256×1024), достаточно простой косвенной адресации. Наконец, при использовании тройной косвенной адресации можно обеспечить доступ к 16777216 блокам (256×256×256).

Файлы в UNIX могут содержать так называемые дыры. Например, процесс может создать пустой файл, с помощью системного вызова lseek(2) сместить файловый указатель относительно начала файла и записать данные. При этом между началом файла и началом записанных данных образуется дыра — незаполненная область. При чтении этой области процесс получит обнуленные байты. Поскольку логические блоки, соответствующие дыре, не содержат данные, не имеет смысла размещать для них дисковые блоки. В этом случае соответствующие элементы массива адресов inode содержат нулевой указатель. Когда процесс производит чтение такого блока, ядро возвращает последовательность нулей. Дисковые блоки размещаются только при записи в соответствующие логические блоки файла.

 

Имена файлов

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

Каталог файловой системы s5fs представляет собой таблицу, каждый элемент которой имеет фиксированный размер в 16 байтов: 2 байта хранят номер индексного дескриптора файла, а 14 байтов — его имя. Это накладывает ограничение на число inode, которое не может превышать 65 535. Также ограничена и длина имени файла: его максимальный размер — 14 символов. Структура каталога приведена на рис. 4.3.

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

Первые два элемента каталога адресуют сам каталог (текущий каталог) под именем "." и родительский каталог под именем "..".

При удалении имени файла из каталога (например, с помощью команды rm(1)), номер inode соответствующего элемента устанавливается равным 0. Ядро обычно не удаляет такие свободные элементы, поэтому размер каталога не уменьшается даже при удалении файлов. Это является потенциальной проблемой для каталогов, в которые временно было помещено большое количество файлов. После удаления большинства из них размер каталога останется достаточно большим, поскольку записи удаленных файлов будут по-прежнему существовать.

Иллюстрацию этого явления в SCO UNIX можно привести, применив команду hd(1M), обеспечивающую вывод неинтерпретированного содержимого файла (шестнадцатеричный дамп).

$ hd .

0000 fc 0a 2e 00 00 00 00 00 00 00 00 00 00 00 00 00

0010 02 00 2е 2е 00 00 00 00 00 00 00 00 00 00 00 00

0020 33 72 6d 61 69 6с 00 00 00 00 00 00 00 00 00 00 3rmail

0030 0а 2с 4е 65 77 73 00 00 00 00 00 00 00 00 00 00 .,News

0040 33 7d 2е 6e 65 77 73 72 63 00 00 00 00 00 00 00 3}.newsrc

0050 00 40 62 69 6e 00 00 00 00 00 00 00 00 00 00 00 .@bin

0060 da 91 64 65 61 64 2е 6с 65 74 74 65 72 00 00 00 ..dead.letter...

0290 00 00 70 69 6e 65 72 63 30 30 30 37 36 39 00 00 ..pinerc000769..

02a0 00 00 30 35 6e 61 64 75 76 61 2е 6а 70 67 00 00 ..05naduva.jpg..

02b0 00 00 30 36 73 70 75 73 74 69 2е 6а 70 67 00 00 ..06spusti.jpg..

02с0 00 00 30 37 67 75 69 74 61 72 2е 6а 70 67 00 00 ..07guitar.jpg..

02d0 00 00 30 38 73 75 6e 73 65 74 2е 6а 70 67 00 00 ..08sunset.jpg..

02е0 00 00 37 31 72 6f 70 65 73 31 2е 6а 70 67 00 00 ..71ropes1.jpg..

Можно заметить, что имен файлов, расположенных во второй части вывода команды hd(1M) на самом деле не существует — об этом свидетельствуют нулевые значения номеров inode, это же подтверждает вывод команды ls(1):

$ ls -а

.newsrc

bin

dead.letter

News

mail

 

Недостатки и ограничения

Файловая систем s5fs привлекательна благодаря своей простоте. Однако обратной стороной медали является низкая надежность и производительность.

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

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

Использование дискового пространства также не оптимально. Для увеличения производительности файловой системы более предпочтительным является использование блоков больших размеров. Это позволяет считывать большее количество данных за одну операцию ввода/вывода. Так, например, в UNIX SVR2 размер блока составлял 512 байтов, а в SVR3 — уже 1024 байтов. Однако поскольку блок может использоваться только одним файлом, увеличение размера блока приводит к увеличению неиспользуемого дискового пространства за счет частичного заполнения последнего блока файла. В среднем для каждого файла теряется половина блока.

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

Наконец, ограничения, накладываемые на длину имени файла (14 символов) и общее максимальное число inode (65 535), также являются слишком жесткими.

Все эти недостатки привели к разработке новой архитектуры файловой системы, которая появилась в версии 4.2BSD UNIX под названием Berkeley Fast File System, или FSS.

 

В версии 4.3BSD UNIX были внесены существенные улучшения в архитектуру файловой системы, повышающие как ее производительность, так и надежность. Новая файловая система получила название Berkeley Fast File System (FFS).

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

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

Организация файловой системы предусматривает логическое деление дискового раздела на одну или несколько групп цилиндров (cylinder group). Группа цилиндров представляет собой несколько последовательных дисковых цилиндров. Каждая группа цилиндров содержит управляющую информацию, включающую резервную копию суперблока, массив inode, данные о свободных блоках и итоговую информацию об использовании дисковых блоков в группе (рис. 4.4).

Рис. 4.4. Структура файловой системы FFS

Для каждой группы цилиндров при создании файловой системы выделяется место под определенное количество inode. При этом обычно на каждые 2 Кбайт блоков хранения данных создается один inode. Поскольку размеры группы цилиндров и массива inode фиксированы, в файловой системе BSD UNIX присутствуют ограничения, аналогичные s5fs.

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

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

Производительность файловой системы существенным образом зависит от размера блока хранения данных. Чем больше размер блока, тем большее количество данных может быть прочитано без поиска и перемещения дисковой головки. Файловая система FFS поддерживает размер блока до 64 Кбайт. Проблема заключается в том, что типичная файловая система UNIX состоит из значительного числа файлов небольшого размера. Это приводит к тому, что частично занятые блоки используются неэффективно, что может привести к потере до 60% полезной емкости диска.

Этот недостаток был преодолен с помощью возможности фрагментации блока. Каждый блок может быть разбит на два, четыре или восемь фрагментов. В то время как блок является единицей передачи данных в операциях ввода/вывода, фрагмент определяет адресуемую единицу хранения данных на диске. Таким образом был найден компромисс между производительностью ввода/вывода и эффективностью хранения данных. Размер фрагмента задается при создании файловой системы, его максимальное значение определяется размером блока (0,5 размера блока), а минимальный — физическими ограничениями дискового устройства, а именно: минимальной единицей адресации диска — сектором.

Информация о свободном пространстве в группе хранится не в виде списка свободных блоков, а в виде битовой карты блоков. Карта блоков, связанная с определенной группой цилиндров, описывает свободное пространство в фрагментах, для определения того, свободен данный блок или нет, ядро анализирует биты фрагментов, составляющих блок. На рис. 4.5 приведен пример карты свободных блоков и соответствия между битами карты, фрагментами и блоками группы цилиндров.

Рис. 4.5. Карта свободных блоков

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

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

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

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

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

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

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

Описанная архитектура является весьма эффективной с точки зрения надежности и производительности. К сожалению, эти параметры файловой системы 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) или поместить его в кэш для дальнейшего использования.

Поле v_vfsp указывает на файловую систему (структуру vfs, о которой мы поговорим в следующем разделе), в которой расположен файл, адресованный данным vnode. Если vnode является точкой монтирования, то поле v_vfsmountednere указывает на подключенную файловую систему, "перекрывающую" данный vnode.

Поле v_data указывает на данные, относящиеся к конкретной реализации реальной файловой системы. Например, для дисковой файловой системы ufs, v_data указывает на запись в таблице in-core inode.

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

Таблица 4.2. Операции с vnode виртуальной файловой системы

Взаимосвязь между независимыми дескрипторами (vnode) и зависимыми от реализации метаданными файла показана на рис. 4.8.

Рис. 4.8. Метаданные файла виртуальной файловой системы

 

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

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

Только после этого ядро сможет выполнять файловые операции, такие как создание, открытие, чтение или запись в файл. Эта операция встраивания получила название подключения или монтирования файловой системы.

Каждая подключенная файловая система представлена на независимом уровне в виде структуры vfs, аналоге записи таблицы монтирования дисковой файловой системы. Структуры vfs всех подключенных файловых систем организованы в виде односвязного списка, в совокупности обеспечивая информацию, необходимую для обслуживания всего иерархического дерева, а также информацию о реальной файловой системе, которые не изменяются на протяжении работы. Первой записью списка всегда является корневая файловая система. В дальнейшем, список vfs мы будем называть устоявшимся термином — таблица монтирования. Поля структуры vfs приведены в табл. 4.3.

Таблица 4.3. Поля структуры vfs

Поле vfs_data содержит указатель на данные реальной файловой системы. Например, для дисковой файловой системы s5fs, это поле указывает на суперблок, размещенный в памяти.

Поле vfs_op указывает на операции файловой системы, которые в терминах объектно-ориентированного подхода могут быть названы виртуальными методами объекта vfs. Возможные операции файловой системы приведены в табл. 4.4. Поскольку они существенным образом зависят от архитектуры и конкретной реализации, поля vfs_op заполняются указателями на соответствующие функции реальной файловой системы при ее монтировании.

Таблица 4.4. Операции файловой системы

Для инициализации и монтирования реальной файловой системы UNIX хранит коммутатор файловых систем (File System Switch), адресующий процедурный интерфейс для каждого типа файловой системы, поддерживаемой ядром. UNIX System V для этого использует глобальную таблицу, каждый элемент которой соответствует определенному типу реальной файловой системы, например s5fs, ufs или nfs. Элемент этой таблицы vfssw имеет поля, указанные в табл. 4.5.

Таблица 4.5. Коммутатор файловых систем

Взаимодействие структур виртуальной файловой системы показано на рис. 4.9.

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

Монтирование файловой системы производится системным вызовом mount(2). В качестве аргументов передаются тип монтируемой файловой системы, имя каталога, к которому подключается файловая система (точка монтирования), флаги (например, доступ к файловой системе только для чтения) и дополнительные данные, конкретный вид и содержимое которых зависят от реализации реальной файловой системы. При этом производится поиск vnode, соответствующего файлу — точке монтирования (операция lookup() или namei() трансляции имени), и проверяется, что файл является каталогом и не используется в настоящее время для монтирования других файловых систем.

Затем происходит поиск элемента коммутатора файловых систем vfssw[], соответствующего типу монтируемой файловой системы. Если такой элемент найден, вызывается операция инициализации, адресованная полем vsw_init(). При этом выполняется размещение специфических для данного типа файловой системы данных, после чего ядро размещает структуру vfs и помещает ее в связанный список, подключенных файловых систем, как это показано на рис. 4.11. Поле vfs_vnodecovered указывает на vnode точки монтирования. Это поле устанавливается нулевым для корневой (root) файловой системы, элемент vfs которой всегда расположен первым в списке подключенных файловых систем. Поле vfs_op адресует вектор операций, определенный для данного типа файловой системы. Наконец, указатель на данный элемент vfs сохраняется в поле v_vfsmountedhere виртуального индексного дескриптора каталога — точки монтирования.

После этого вызывается операция vfs_mount() соответствующая данному типу файловой системы. Конкретные действия определяются реализацией файловой системы и могут существенно различаться. Например, операция монтирования локальной файловой системы ufs предусматривает считывание в память метаданных системы, таких как суперблок, в то время как монтирование удаленной NFS файловой системы включает передачу сетевого запроса файловому серверу. Однако монтирование предусматривает выполнение и ряда общих операций, включающих:

□ проверку соответствующих прав на выполнение монтирования;

□ размещение и инициализацию специфических для файловой системы данного типа данных, сохранение адреса этих данных в поле vfs_data элемента vfs;

□ размещение vnode для корневого каталога подключаемой файловой системы, доступ к которому осуществляется с помощью операции vfs_root().

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

Определение корневого vnode для подключенной файловой системы производится с помощью операции vfs_root(). Заметим, что в некоторых реализациях независимой файловой системы (например, в SCO UNIX, хотя там используется другая терминология) одно из полей записи таблицы монтирования явно указывало на корневой vnode. Подход, предложенный фирмой Sun Microsystems, позволяет не хранить корневой vnode постоянно, размещая его только при необходимости работы с файловой системой. Это минимизирует ресурсы, занимаемые подключенными файловыми системами, которые продолжительное время не используются.

На рис. 4.10 приведен вид логического файлового дерева до и после монтирования файловой системы А к каталогу /usr/local. На рис. 4.11 приведен вид виртуальной файловой системы после этой операции монтирования.

Рис. 4.10. Монтирование файловой системы А к корневой файловой системе

Рис. 4.11. Схема монтирования файловых систем различных типов

Исследовать описанные структуры данных можно с помощью утилиты crash(1M). Для этого применяются команды vfs и mode, отображающие содержимое соответствующих структур данных. Приведем пример такого исследования файлового дерева операционной системы Solaris 2.5:

# crash

dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout

> !mount

/ on /dev/dsk/c0t3d0s0 read/write on Tue Feb 25 15:29:11 1997

/usr/local on /dev/dsk/c0t0d0s0 read/write on Tue Feb 25 15:29:13 1997

/tmp on swap read/write on Tue Feb 25 15:29:13 1997

/dev/fd on fd read/write/setuid on Tue Feb 25 15:29:11 1997

/proc on /proc read/write/setuid on Tue Feb 25 15:29:11 1997

/cdrom/unnamed_cdrom on /dev/dsk/c0t6d0 ronly on Mon Mar 25 15:29:43 1997

> vfs

FSTYP BSZ  MAJ/MIN   FSID VNCOVERED    PDATA BCOUNT FLAGS

ufs   8192  32,24  800018         0 f5b79b78      0 notr

ufs   8192  32,0   800000  f5c29ad0 f5c28c88      0 notr

tmpfs 4096   0,0        0  f5958d18 f5d16ee0      0 notr

fd    1024 158,0  2780000  f5c4f5d8        0      0

proc  1024 156,0  2700000  f5c4f718        0 283920

hsfs  2048  91,1  b9d02de5 f5f20698 f5b60d98      0 rd

Мы распечатали список подключенных файловых систем (команда mount(1M)) и элементы vfs таблицы монтирования. Рассмотрим подробнее vnode точки монтирования файловой системы раздела /dev/dsk/c0t0d0s0.

> vnode f5c29ad0

VCNT VFSMNTED     VFSP STREAMP VTYPE RDEV VDATA    VFILOCKS VFLAG

   2 f5c25c60 f0286570       0 d     -    f5c29ac8        0 -

Удостоверимся, что поле v_vfsmountedhere (VFSMNTED) адресует элемент vfs подключенной файловой системы, а поле v_fsp (VFSP) указывает на элемент корневой файловой системы.

> vfs f5c25c60

FSTYP  BSZ MAJ/MIN   FSID VNCOVERED    PDATA BCOUNT FLAGS

ufs   8192  32,0   800000  f5c29ad0 f5c28c88      0 notr

> vfs f0286570

FSTYP  BSZ MAJ/MIN   FSID VNCOVERED    PDATA BCOUNT FLAGS

ufs   8192  32,24  800018         0 f5b79b78      0 notr

Наконец, посмотрим на содержимое inode файловой системы ufs, адресованного полем v_data (VDATA) виртуального индексного дескриптора:

> ui f5c29ac8

UFS INODE TABLE SIZE = 1671

SLOT MAJ/MIN INUMB RCNT LINK UID GID SIZE    MODE FLAGS

   -  32,24   7552    2    2   0   0  512 d---755 rf

Полученная информация показывает, что запись таблицы inode ufs адресует дисковый индексный дескриптор с номером 7552 (INUMB). Для того чтобы узнать имя файла, используем команду ncheck(1M):

> !ncheck -i 7552

/dev/dsk/c0t3d0s0:

7552 /usr/local

 

Трансляция имен

Прикладные процессы, запрашивая услуги файловой системы, обычно имеют дело с именем файла или файловым дескриптором, полученным в результате определенных системных вызовов. Однако ядро системы для обеспечения работы с файлами использует не имена, а индексные дескрипторы. Таким образом, необходима трансляция имени файла, передаваемого, например, в качестве аргумента системному вызову open(2), в номер соответствующего vnode.

В табл. 4.6 приведены системные вызовы, для выполнения которых требуется трансляция имени файла.

Таблица 4.6. Системные вызовы, требующие трансляции имени

Говоря формально, полное имя файла представляет собой последовательность слов, разделенных символом '/'. Каждый компонент имени, кроме последнего, является именем каталога. Последний компонент определяет собственно имя файла. При этом полное имя может быть абсолютным или относительным. Если полное имя начинается с символа '/', представляющего корневой каталог общего логического дерева файловой системы, то оно является абсолютным, однозначно определяющим файл из любого места файловой системы. В противном случае, имя является относительным и адресует файл относительно текущего каталога. Примером относительного имени может служить include/sys/user.h, а абсолютное имя этого файла — /usr/include/sys/user.h. Как следует из этих рассуждений, два каталога играют ключевую роль при трансляции имени: корневой каталог и текущий каталог. Каждый процесс адресует эти каталоги двумя полями структуры u_area:

В зависимости от имени файла трансляция начинается с vnode, адресованного либо полем u_cdir, либо u_rdir. Трансляция имени осуществляется покомпонентно, при этом для vnode текущего каталога вызывается соответствующая ему операция vn_lookup(), в качестве аргумента которой передается имя следующего компонента. В результате операции возвращается vnode, соответствующий искомому компоненту.

Если для vnode каталога установлен указатель vn_vfsmountedhere, то данный каталог является точкой монтирования. Если имя файла требует дальнейшего спуска по дереву файловой системы (т.е. пересечения точки монтирования), то операция vn_lookup() следует указателю vn_vfsmountedhere для перехода в подключенную файловую систему и вызывает для нее операцию vfs_root для получения ее корневого vnode. Трансляция имени затем продолжается с этого места.

Пересечение границы файловых систем возможно и при восхождении по дереву, например, если имя файла задано указанием родительского каталога — ../../myfile.txt. Если при движении в этом направлении по пути встречается корневой vnode подключенной файловой системы (установлен флаг VROOT в поле v_flag), то операция vn_lookup() следует указателю vfs_vnodecovered, расположенному в записи vfs этой файловой системы. При этом происходит пересечение границы файловых систем, и дальнейшая трансляция продолжается с точки монтирования.

Если искомый файл является символической связью, и системный вызов, от имени которого происходит трансляция имени, "следует" символической связи, операция vn_lookup() вызывает vn_readlink() для получения имени целевого файла. Если оно является абсолютным (т.е. начинается с "/"), то трансляция начинается с vnode корневого каталога, адресованного полем u_rdir области u-area.

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

 

Как было показано в главе 2, процесс совершает операции с файлами, адресуя их при помощи файловых дескрипторов — целых чисел, имеющих локальное для процесса значение. Это значит, что файловый дескриптор одного процесса может адресовать совершенно другой файл, нежели файловый дескриптор с таким же номером, используемый другим процессом. Процесс получает файловый дескриптор с помощью ряда системных вызовов, например, open(2) или creat(2)), выполняющих операцию трансляции имени, в результате которой выделяемый файловый дескриптор адресует определенный (или vnode) и, соответственно, файл файловой системы.

На рис. 4.12 показаны основные структуры ядра, необходимые для доступа процесса к файлу.

Рис. 4.12. Внутренние структуры доступа к файлу

Файловый дескриптор, используемый для доступа процесса к файлу, является индексом таблицы файловых дескрипторов (file descriptor table). Каждый процесс имеет собственную таблицу файловых дескрипторов, которая расположена в его u-area. На рис. 4.12 показаны два процесса, каждый из которых использует собственную таблицу файловых дескрипторов.

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

Как следует из рис. 4.12, несколько записей системной файловой таблицы могут адресовать один и тот же файл, который представлен единственной записью в таблице vnode.

 

Файловые дескрипторы

Файловый дескриптор представляет собой неотрицательное целое число, возвращаемое системными вызовами, такими как creat(2), open(2) или pipe(2). После получения файлового дескриптора процесс может использовать его для дальнейшей работы с файлом, например с помощью системных вызовов read(2), write(2), close(2) или fcntl(2).

Ядро обеспечивает работу процесса с файлами, используя различные структуры данных, часть из которых расположена в u-area процесса. Напомним, что эта область описывается структурой user. В табл. 4.7 приведены поля структуры user, которые используются ядром для обеспечения доступа процесса к файлу.

Таблица 4.7. Поля структуры user, связанные с файловым дескриптором

Файловый дескриптор связан с этими двумя полями и, таким образом, обеспечивает доступ к соответствующему элементу файловой таблицы (структуре данных file).

В настоящее время в качестве единственного флага файлового дескриптора определен флаг FD_CLOEXEC. Если этот флаг установлен, то производится закрытие файлового дескриптора (аналогично явному вызову close(2)) при выполнении процессом системного вызова exec(2)). При этом для запущенной программы не происходит наследования файлового дескриптора и доступа к файлу.

Более старые версии UNIX используют статическую таблицу дескрипторов, которая целиком хранится в u-area. Номер дескриптора является индексом этой таблицы. Таким образом, размер таблицы, которая обычно содержит 64 элемента, накладывает ограничение на число одновременно открытых процессом файлов. В современных версиях таблица размещается динамически и может увеличиваться при необходимости. Следует, однако, иметь в виду, что и в этом случае максимальное число одновременно открытых файлов регламентируется пределом RLIMIT_NOFILE, который рассматривался в разделе "Ограничения" главы 2. В некоторых версиях, например, Solaris 2.5, данные файловых дескрипторов хранятся не в виде таблицы, а в виде блоков структур uf_entry, поля которой аналогичны приведенным в табл. 4.7.

Содержимое таблицы дескрипторов процесса можно посмотреть с помощью утилиты crash(1M). Команда user покажет содержимое u-area процесса. Например, для текущего командного интерпретатора мы получим следующую информацию:

# crash

> 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: 1ebc, type: exec

 vnode of current directory: f5b95e40

OPEN FILES, POFILE FLAGS, AND THREAD REFCNT:

  [0] : F 0xf62b6030, 0, 0 [1] : F 0xf62b6030, 0, 0

  [2] : F 0xf62b6030, 0, 0

 cmask: 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:

...

 

Файловая таблица

Поля файлового дескриптора u_ofile и u_pofile содержат начальную информацию, необходимую для доступа процесса к данным файла. Дополнительная информация находится в системной файловой таблице и таблице индексных дескрипторов. Для обеспечения доступа процесса к данным файла ядро должно полностью создать цепочку от файлового дескриптора до vnode и, соответственно, до блоков хранения данных, как показано на рис. 4.12.

Каждый элемент файловой таблицы содержит информацию, необходимую для управления работой с файлом. Если несколько процессов открывают один и тот же файл, каждый из них получает собственный элемент файловой таблицы, хотя все они будут работать с одним и тем же файлом. Важнейшие поля элемента файловой таблицы приведены ниже:

Для иллюстрации обсуждения продолжим работу с утилитой crash(1M). С помощью команды user в предыдущем разделе были получены адреса элементов файловой таблицы для стандартного ввода (fd=0), вывода (fd=1) и вывода сообщений об ошибках (fd=2). Заметим, что все они указывают на один и тот же элемент. С помощью команды file исследуем его содержимое:

> file 0xf62b6030

ADDRESS  RCNT TYPE/ADDR     OFFSET FLAGS

f62b6030    9 SPEC/f5e91c1c  15834 read write

> vnode f5e91c1c

VCNT VFSMNTED     VFSP  STREAMP VTYPE RDEV     VDATA VFILOCKS VFLAG

   2        0 f0286570 f5c6b2a0 c     24,26 f5e91c18        0 -

Поскольку это специальный файл устройства (об этом свидетельствует поле TYPE элемента файловой таблицы), поле v_data (VDATA) vnode указывает не на inode файловой системы ufs, а на snode — индексный дескриптор логической файловой системы specfs, обслуживающей специальные файлы устройств. Более подробно этот интерфейс будет рассматриваться в следующей главе. Таким образом, для продолжения путешествия по структурам данных ядра, следует обратиться к snode, адрес которого указан в поле VDATA.

> snode f5e91c18

SNODE TABLE SIZE = 256

HASH-SLOT MAJ/MIN   REALVP COMMONVP NEXTR SIZE COUNT FLAGS

-          24,26  f5f992e8 f636b27c     0    0     0 up ас

Поле s_realvp (REALVP) указывает на vnode файла реальной файловой системы (в данном случае ufs). Поэтому далее поиск аналогичен проделанному при исследовании таблицы монтирования.

> vnode f5f992e8

VCNT VFSMNTED     VFSP STREAMP VTYPE RDEV     VDATA VFILOCKS VFLAG

   2        0 f0286570       0     с 24,26 f5f992e0        0 -

> ui f5f992e0

 UFS INODE TABLE SIZE = 1671

SLOT MAJ/MIN  INUMB RCNT LINE UID GID SIZE MODE    FLAGS

  -   32,24  317329    2    1 286   7    0 c---620 rf

> ! ncheck. -i 317329

/dev/dsk/c0t3d0s0:

317329 /devices/pseudo/pts@0:26

В результате мы определили имя специального файла устройства (в данном случае — это псевдотерминал), на которое производится ввод и вывод командного интерпретатора.

 

Блокирование доступа к файлу

Традиционно архитектура файловой подсистемы UNIX разрешает нескольким процессам одновременный доступ к файлу для чтения и записи. Хотя операции записи и чтения, осуществляемые с помощью системных вызовов read(2) или write(2), являются атомарными, в UNIX по умолчанию отсутствует синхронизация между отдельными вызовами. Другими словами, между двумя последовательными вызовами read(2) одного процесса другой процесс может модифицировать данные файла. Это, в частности, может привести к несогласованным операциям с файлом, и как следствие, к нарушению целостности его данных. Такая ситуация является неприемлемой для многих приложений.

UNIX позволяет обеспечить блокирование заданного диапазона байтов файла или записи файла. Для этого служат базовый системный вызов управления файлом fcntl(2) и библиотечная функция lockf(3C), предназначенная специально для управления блокированием. При этом перед фактической файловой операцией (чтения или записи) процесс устанавливает блокирование соответствующего типа (для чтения или для записи). Если блокирование завершилось успешно, это означает, что требуемая файловая операция не создаст конфликта или нарушения целостности данных, например, при одновременной записи в файл несколькими процессами.

По умолчанию блокирование является рекомендательным (advisory lock). Это означает, что кооперативно работающие процессы могут руководствоваться созданными блокировками, однако ядро не запрещает чтение или запись в заблокированный участок файла. При работе с рекомендательными блокировками процесс должен явно проверять их наличие с помощью тех же функций fcntl(2) и lockf(3C).

Мы уже встречались с использованием системного вызова fnctl(2) для блокирования записей файла в главе 2. Там же была упомянута структура flock, служащая для описания блокирования. Поля этой структуры описаны в табл. 4.8.

Таблица 4.8. Поля структуры flock

Как следует из описания поля l_type структуры flock, существуют два типа блокирования записи: для чтения (F_RDLCK) и для записи (F_WRLCK). Правила блокирования таковы, что может быть установлено несколько блокирований для чтения на конкретный байт файла, при этом в установке блокирования для записи на этот байт будет отказано. Напротив, блокирование для записи на конкретный байт должно быть единственным, при этом в установке блокирования для чтения будет отказано.

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

...

struct flock lock;

...

/* Заполним описание lock с целью блокирования всего файла

для записи */

lock.l_type = FWRLCK;

lock.l_start = 0;

lock.whence = SEEK_SET;

lock.len = 0;

/* Заблокируем файл. Если блокирования, препятствующие

   данной операции, уже существуют — ждем их снятия */

fcntl(fd, SETLKW, &lock);

/* Запишем данные в файл - нам никто не помешает */

write(fd, record, sizeof(record));

/* Снимем блокирование */

lock.l_type = F_UNLK;

fcntl(fd, SETLKW, &lock);

В отличие от рекомендательного в UNIX существует обязательное блокирование (mandatory lock), при котором ограничение на доступ к записям файла накладывается самим ядром. Реализация обязательных блокировок может быть различной. Например, в SCO UNIX (SVR3) снятие бита x для группы и установка бита SGID для группы приводит к тому, что блокировки, установленные fcntl(2) или lockf(3C), станут обязательными. UNIX SVR4 поддерживает установку блокирования отдельно для записи и для чтения, обеспечивая тем самым доступ для чтения многим, а для записи — только одному процессу. Эти установки также осуществляются с помощью системного вызова fcntl(2). Следует иметь в виду, что использование обязательного блокирования таит потенциальную опасность. Например, если процесс блокирует доступ к жизненно важному системному файлу и по каким-либо причинам теряет контроль, это может привести к аварийному останову операционной системы.

 

Во введении отмечалось, что работа файловой подсистемы тесно связана с обменом данными с периферийными устройствами. Для обычных файлов и каталогов — это устройство, на котором размещается соответствующая файловая система, для специальных файлов устройств — это принтер, терминал, или сетевой адаптер. Не вдаваясь в подробности подсистемы ввода/вывода, рассмотрим, как во многих версиях UNIX организован обмен данными с дисковыми устройствами — традиционным местом хранения подавляющего большинства файлов.

Не секрет, что операции дискового ввода/вывода являются медленными по сравнению, например, с доступом к оперативной или сверхоперативной памяти. Время чтения данных с диска и копирования тех же данных в памяти может различаться в несколько тысяч раз. Поскольку основные данные хранятся на дисковых накопителях, дисковый ввод/вывод является узким местом операционной системы. Для повышения производительности дискового ввода/вывода и, соответственно, всей системы в целом, в UNIX используется кэширование дисковых блоков в памяти.

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

Рис. 4.13. Роль буферного кэша

 

Внутренняя структура буферного кэша

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

Основные поля структуры buf приведены в табл. 4.9.

Таблица 4.9. Поля структуры buf

Поле b_flags хранит различные флаги связанного с заголовком буфера. Часть флагов используется буферным кэшем, а часть — драйвером устройства. Например, с помощью флага B_BUSY осуществляется синхронизация доступа к буферу. Флаг B_DELWRI отмечает буфер как модифицированный, или "грязный", требующий сохранения на диске перед повторным использованием. Флаги B_READ, B_WRITE, B_ASYNC, B_DONE и B_ERROR используются драйвером диска. Более подробно операция ввода/вывода для драйвера будет рассмотрена в следующей главе.

Буферный кэш использует механизм отложенной записи (write-behind), при котором модификация буфера не вызывает немедленной записи на диск. Такие буферы отмечаются как "грязные", а синхронизация их содержимого с дисковыми данными происходит через определенные промежутки времени. Примерно одна треть операций дискового ввода/вывода приходится на запись, причем один и тот же буфер может на протяжении ограниченного промежутка времени модифицироваться несколько раз. Поэтому буферный кэш позволяет значительно уменьшить интенсивность записи на диск и реорганизовать последовательность записи отдельных буферов для повышения производительности ввода/вывода (например, уменьшая время поиска, группируя запись соседних дисковых блоков). Однако этот механизм имеет свои недостатки, поскольку может привести к нарушению целостности файловой системы в случае неожиданного останова или сбоя операционной системы.

 

Операции ввода/вывода

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

Рис. 4.14. Схема работы буферного кэша

Когда процессу требуется прочитать или записать данные он использует системные вызовы read(2) или write(2), направляя тем самым запрос файловой подсистеме. В свою очередь файловая подсистема транслирует этот запрос в запрос на чтение или запись соответствующих дисковых блоков файла и направляет его в буферный кэш. Прежде всего кэш просматривается на предмет наличия требуемого блока в памяти. Если соответствующий буфер найден, его содержимое копируется в адресное пространство процесса в случае чтения и наоборот при записи, и операция завершается. Если блок в кэше не найден, ядро размещает буфер, связывает его с дисковым блоком с помощью заголовка buf и направляет запрос на чтение драйверу устройства. Обычно используется схема чтения вперед (read-ahead), когда считываются не только запрашиваемые блоки, но и блоки, которые с высокой вероятностью могут потребоваться в ближайшее время (рис. 4.14, а). Таким образом, последующие вызовы read(2) скорее всего не потребуют дискового ввода/вывода, а будут включать лишь копирование данных из буферов в память процесса, — операция, которая, как отмечалось, обладает на несколько порядков большей производительностью (рис. 4.14, б–в). При запросе на модификацию блока изменения также затрагивают только буфер кэша. При этом ядро помечает буфер как "грязный" в заголовке buf (рис. 4.14, г). Перед освобождением такого буфера для повторного использования, его содержимое должно быть предварительно сохранено на диске (рис. 4.14, д).

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

Не заблокированные буферы помечаются как свободные и помещаются в специальный список. Буферы в этом списке располагаются в порядке наименее частого использования (Least Recently Used, LRU). Таким образом, когда ядру необходим буфер, оно выбирает тот, к которому не было обращений в течение наиболее продолжительного промежутка времени. После того как работа с буфером завершена, он помещается в конец списка и является наименее вероятным кандидатом на освобождение и повторное использование. Поэтому, если процесс вскоре опять обратится к тому же блоку данных, операция ввода/вывода по-прежнему будет происходить с буфером кэша. С течением времени буфер перемещается в направлении начала очереди, но при каждом последующем обращении к нему, будет помещен в ее конец.

Основной проблемой, связанной с буферным кэшем, является "старение" информации, хранящейся в дисковых блоках, образы которых находятся в буферном кэше. Как следует из схемы работы кэша, большинство изменений затрагивают только данные в соответствующих буферах, в то время, как дисковые блоки хранят уже устаревшую информацию. Разумеется в нормально работающей системе проблемы как таковой не возникает, поскольку в операциях ввода/вывода всегда используются свежие данные буферного кэша. Однако при аварийном останове системы, это может привести к потере изменений данных файлов, сделанных процессами непосредственно перед остановом.

Для уменьшения вероятности таких потерь в UNIX имеется несколько возможностей:

□ Во-первых, может использоваться системный вызов sync(2), который обновляет все дисковые блоки, соответствующие "грязным" буферам. Необходимо отметить, что sync(2) не ожидает завершения операции ввода/вывода, таким образом после возврата из функции не гарантируется, что все "грязные" буферы сохранены на диске.

□ Во-вторых, процесс может открыть файл в синхронном режиме (указав флаг O_SYNC в системном вызове open(2)). При этом все изменения в файле будут немедленно сохраняться на диске.

□ Наконец, через регулярные промежутки времени в системе пробуждается специальный системный процесс — диспетчер буферного кэша (в различных версиях UNIX его названия отличаются, чаще всего используется fsflush или bdflush). Этот процесс освобождает "грязные" буферы, сохраняя их содержимое в соответствующих дисковых блоках (рис. 4.14, д).

 

Кэширование в SVR4

Центральной концепцией в архитектуре виртуальной памяти SVR4 является отображение файлов. При этом подходе все адресное пространство может быть представлено набором отображений различных файлов в память. Действительно, в страницы памяти, содержащие кодовые сегменты, отображаются соответствующие секции исполняемых файлов. Процесс может задать отображение с помощью системного вызова mmap(2), при этом страницам памяти будут соответствовать определенные участки отображаемого файла. Даже области памяти, содержимое которых изменяется и не связано ни с каким файлом файловой системы, т.н. анонимные страницы, можно отобразить на определенные участки специального файла устройства, отвечающего за область свопинга (именно там сохраняются анонимные объекты памяти). При этом фактический обмен данными между памятью и устройствами их хранения, инициируется возникновением страничной ошибки. Такая архитектура позволяет унифицировать операции ввода/вывода практически для всех случаев.

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