Текст книги "Операционная система UNIX"
Автор книги: Андрей Робачевский
Жанр:
ОС и Сети
сообщить о нарушении
Текущая страница: 24 (всего у книги 39 страниц)
Файловая система BSD UNIX
В версии 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 представлена структурой, имеющей следующие поля:
d_ino | Номер inode (индекс в массив ilist) |
d_reclen | Длина записи |
d_namlen | Длина имени файла |
d_name[] | Имя файла |
Имя файла имеет переменную длину, дополненную нулями до 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
u_short vflag | Флаги vnode |
u_short v_count | Число ссылок на vnode |
struct filock *v_filocks | Блокировки файла |
struct vfs *v_vfsmountedhere | Указатель на подключенную файловую систему, если vnode является точкой монтирования |
struct vfs *v_vfsp | Указатель на файловую систему, в которой находится файл |
enum vtype v_type | Тип vnode: обычный файл, каталог, специальный файл устройства, символическая связь, сокет |
caddr_t v_data | Указатель на данные, относящиеся к реальной файловой системе |
struct op | Операции 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 виртуальной файловой системы
int (*vn_open)() | Открыть vnode. Если операция предусматривает создание клона (размножение), то в результате будет размещен новый vnode. Обычно операции такого типа характерны для специальных файлов устройств. |
int (*vn_close)() | Закрыть vnode. |
int (*vn_read)() | Чтение данных файла, адресованного vnode. |
int (*vn_write)() | Запись в файл, адресованный vnode. |
int (*vn_ioctl)() | Задание управляющей команды. |
int (*vn_getaddr)() | Получить атрибуты vnode: тип vnode, права доступа, владелец-пользователь, владелец-группа, идентификатор файловой системы, номер inode, число связей, размер файла, оптимальный размер блока для операций ввода/вывода, время последнего доступа, время последней модификации, время последней модификации vnode, число занимаемых блоков. |
int (*vn_setaddr)() | Установить атрибуты vnode. Могут быть изменены UID, GID, размер файла и времена доступа и модификации. |
int (*vn_access)() | Проверить права доступа к файлу, адресованному vnode. При этом производится отображение между атрибутами доступа файлов UNIX и атрибутами реальной файловой системы (например, DOS). |
int (*vn_lookup)() | Произвести трансляцию имени файла в соответствующий ему vnode. |
int (*vn_create)() | Создать новый файл и соответствующий ему vnode. |
int (*vn_remove)() | Удалить имя файла в указанном vnode каталоге. |
int (*vn_link)() | Создать жесткую связь между именем файла и vnode. |
int (*vn_mkdir)() | Создать новый каталог в указанном vnode каталоге. |
int (*vn_rmdir)() | Удалить каталог. |
int (*vn_readdir)() | Считать записи каталога, адресованного vnode. |
int (*vn_symlink)() | Создать символическую связь между новым именем и именем файла, расположенном в указанном vnode каталоге. |
int (*vn_readlink)() | Чтение файла – символической связи. |
int (*vn_fsync)() | Синхронизировать содержимое файла – записать все кэшированные данные. |
int (*vn_inactive)() | Разрешить удаление vnode, т.к. число ссылок на vnode из виртуальной файловой системы стало равным нулю. |
Взаимосвязь между независимыми дескрипторами (vnode) и зависимыми от реализации метаданными файла показана на рис. 4.8.
Рис. 4.8. Метаданные файла виртуальной файловой системы
Монтирование файловой системыПрежде чем может состояться работа с файлами, соответствующая файловая система должна быть встроена в существующее иерархическое дерево.
Только после этого ядро сможет выполнять файловые операции, такие как создание, открытие, чтение или запись в файл. Эта операция встраивания получила название подключения или монтирования файловой системы.
Каждая подключенная файловая система представлена на независимом уровне в виде структуры vfs, аналоге записи таблицы монтирования дисковой файловой системы. Структуры vfs всех подключенных файловых систем организованы в виде односвязного списка, в совокупности обеспечивая информацию, необходимую для обслуживания всего иерархического дерева, а также информацию о реальной файловой системе, которые не изменяются на протяжении работы. Первой записью списка всегда является корневая файловая система. В дальнейшем, список vfs мы будем называть устоявшимся термином – таблица монтирования. Поля структуры vfs приведены в табл. 4.3.
Таблица 4.3. Поля структуры vfs
struct vfs *vfs_next | Следующая файловая система в списке монтирования. |
struct vfsops *vfs_op | Операции файловой системы. |
struct vnode *vfs_vnodecovered | vnode, перекрываемый файловой системой. |
int vfs_flag | Флаги: только для чтения, запрещен бит SUID и т.д. |
int vfs_bsize | Размер блока файловой системы. |
caddr_t vfs_data | Указатель на специфические данные, относящиеся к реальной файловой системе. |
Поле vfs_data содержит указатель на данные реальной файловой системы. Например, для дисковой файловой системы s5fs, это поле указывает на суперблок, размещенный в памяти.
Поле vfs_op указывает на операции файловой системы, которые в терминах объектно-ориентированного подхода могут быть названы виртуальными методами объекта vfs. Возможные операции файловой системы приведены в табл. 4.4. Поскольку они существенным образом зависят от архитектуры и конкретной реализации, поля vfs_op заполняются указателями на соответствующие функции реальной файловой системы при ее монтировании.
Таблица 4.4. Операции файловой системы
int (*vfs_mount)() | Подключает файловую систему. Обычно операция включает размещение суперблока в памяти и инициализацию записи в таблице монтирования. |
int (*vfs_unmount)() | Отключает файловую систему. Операция включает актуализацию данных файловой системы на накопителе (например, синхронизацию дискового суперблока и его образа в памяти). |
int (*vfs_root)() | Возвращает корневой vnode файловой системы. |
int (*vfs_statfs)() | Возвращает общую информацию о файловой системе, в частности: размер блока хранения данных, число блоков, число свободных блоков, число inode. |
int (*vfs_sync)() | Актуализирует все кэшированные данные файловой системы. |
int (*vfs_fid)() | Возвращает файловый идентификатор (fid – file Identifier), однозначно адресующий файл в данной файловой системе. В качестве fid может, например, выступать номер inode реальной файловой системы. |
int (*vfs_vget)() | Возвращает указатель на vnode для файла данной файловой системы, адресованного fid. |
Для инициализации и монтирования реальной файловой системы UNIX хранит коммутатор файловых систем (File System Switch), адресующий процедурный интерфейс для каждого типа файловой системы, поддерживаемой ядром. UNIX System V для этого использует глобальную таблицу, каждый элемент которой соответствует определенному типу реальной файловой системы, например s5fs, ufs или nfs. Элемент этой таблицы vfssw имеет поля, указанные в табл. 4.5.
Таблица 4.5. Коммутатор файловых систем
char *vsw_name | Имя типа файловой системы |
int (*vsw_init)() | Адрес процедуры инициализации |
struct vfsops *vsw_vfsops | Указатель на вектор операций файловой системы |
long vsw_flag | Флаги |
Взаимодействие структур виртуальной файловой системы показано на рис. 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
