Файл: Учебнометодическое пособие Томск 2016 2 удк 004. 451(075. 8) Ббк 32. 973. 2018. 2я73 к 754 Рецензенты.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 305
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
6.3.2 Распределение памяти
Как следует из п. 6.2, аппаратура управления сегментами обеспечивает два свойства линейных виртуальных адресов: 1) каждый такой адрес не может быть больше 4 Гбайт; 2) любой виртуальный сегмент отображается на непре- рывный участок линейной памяти. С учетом этих свойств сохраняется большая свобода выбора начальных линейных адресов сегментов, записываемых ОС в дескрипторы сегментов (поле В на рисунках 6.3–6.5). Эти адреса выбираются
ОС следующим образом.
Во-первых, программа каждого процесса «загружается» в собственную линейную виртуальную память размером 4 Гбайта.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Линейная виртуальная память (ЛВП) – абстракция, ис-
пользуемая не самой программой (она работает с сегментной вир-
туальной памятью), а операционной системой.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Во-вторых, в эту ЛВП «загружается» и сама ОС. В UNIX используется распределение линейной виртуальной памяти процесса, изображенное на ри- сунке 6.12. При этом 3 Гбайта с меньшими адресами отводятся самой приклад- ной программе, а 1 Гбайт с большими адресами – для ядра ОС. Причем систем- ные DLL обычно располагаются вверху прикладной части ЛВП.
Рис. 6.12 Отображение линейной виртуальной памяти на реальную ОП
175
В-третьих, если в ходе выполнения процесса ему понадобится дополни- тельная ОП, то запрашиваемый объем будет выделен ОС из подходящей сво- бодной области ЛВП динамически.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Всякое назначение памяти процессу, осуществляемое в ходе
его выполнения, называется динамическим распределением па-
мяти. Статическое распределение – память выделяется при со-
здании процесса.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
В-четвертых, ОС выполняет «загрузку» сегментов процесса в ЛВП путем записи начального линейного виртуального адреса каждого сегмента в его де- скриптор. При этом сегменты ядра (их дескрипторы находятся в GDT) всегда
«загружены» в ЛВП по одним и тем же адресам.
В-пятых, содержимое ЛВП используется ОС для выполнения записей в каталог таблиц страниц и в сами таблицы страниц (инициализация таблиц).
Один каталог страниц обычно используется для адресации памяти одного про- цесса. При этом из 1 024 строк каталога 256 строк соответствуют ОС, а 768 строк – прикладной программе. (При смене на ЦП выполняемого процес- са 256 строк в каталоге не меняются, а заменяются лишь 768 строк.) Если
4 Мбайта ЛВП, соответствующие данной строке каталога, содержат какую-то информацию, то в эту строку ОС помещает указатель на соответствующую таб- лицу страниц. Иначе – строка каталога содержит пустой указатель.
Таблица страниц, соответствующая непустой строке каталога, может со- держать до 1 024 строк, каждая из которых содержит дескриптор одной логиче- ской страницы программы. Так как объем одной страницы составляет
4 096 байтов, то максимальный объем ЛВП, соответствующий одной таблице страниц, составляет 4 Мбайта. Любая часть этого объема может соответство- вать «пустым» страницам. Так как ОС ведет учет распределения ЛВП, то «пу- стые» страницы ей известны, и она не создает для них дескрипторы в таблице страниц.
Естественно, что при создании процесса ОС распределяет ему не только
ЛВП, но и реальную ОП. Не предоставив процессу хотя бы небольшое число физических страниц, нельзя обеспечить его выполнение. При этом системная часть программы процесса (256 строк в каталоге таблиц страниц) всегда отоб- ражается на одну и ту же часть реальной ОП (с меньшими адресами). А при- кладная часть ЛВП отображается на ту совокупность физических страниц, ко-
176 торые ОС выделила процессу. Страничное распределение ОП обладает тем су- щественным достоинством, что вследствие одинаковой длины страниц любая логическая страница может быть загружена в любую физическую страницу.
Поэтому не только страницы процесса, но и страницы логического сегмента не образуют непрерывный раздел ОП, а располагаются в произвольных местах памяти.
Благодаря свопингу страниц число логических страниц процесса может быть значительно больше, чем выделенное ему число физических страниц. Для организации такого свопинга аппаратура процессора i80386 предоставляет в помощь ОС исключение отказ страницы, а также специальные биты в де- скрипторах страниц, аналогичные соответствующим битам в дескрипторе таб- лицы страниц (см. рис. 6.7):
1) P – бит присутствия страницы в памяти (1 – страница в ОП; 0 – нет);
2) бит D – устанавливается в 1, если была выполнена запись в страницу;
3) AVL – три бита, которые ОС может использовать по своему усмотре- нию.
Совместная работа аппаратуры и ядра ОС при реализации страничного свопинга заключается в следующем. Выполнив разделение очередного вирту- ального линейного адреса, аппаратура ЦП проверяет бит P в искомом дескрип- торе страницы. Если
P 1
, то выполнение программы продолжается, иначе – возникает исключение «отказ страницы». Его обработчик подкачивает требуе- мую страницу из ВП.
Обычно страница загружается на место ранее загруженной страницы, ко- торая или копируется из ОП на диск (если бит
D 1
), или нет (бит
D 0
). Для определения откачиваемой страницы могут использоваться различные крите- рии. Например, в качестве такой страницы может быть выбрана та, к которой было сделано наименьшее число обращений. В качестве счетчика числа обра- щений может быть использовано поле AVL дескриптора страницы.
Распределение ОП, основанное на страничном свопинге, обладает тем существенным достоинством по сравнению с сегментным свопингом, что вследствие одинаковой длины страниц размещение одной страницы в ОП мо- жет быть выполнено вместо любой другой. Поэтому при размещении в памяти новой страницы не требуется выполнять каких-либо перемещений ранее загру- женных страниц.
Что касается защиты информации в ОП, то аппаратура управления стра- ницами в i80386 предоставляет для этого единственное средство: при выполне-
177 нии любой машинной команды, выполняющей запись в ОП, аппаратно прове- ряется бит W в дескрипторе той страницы, в которую выполняется запись. При
W 1 команда записи производится, а при
W 0 возникает исключение. Эффек- тивность данного средства существенно ниже защитных действий, выполняе- мых аппаратурой управления сегментами (см. пп. 6.2.3).
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Контрольные вопросы по главе 6
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
1. Используется ли регистр CS для защиты информации в ОП?
2. Используется ли дескриптор сегмента процесса для защиты информа- ции в ОП?
3. Используется ли регистр EAX для защиты информации в ОП?
4. Как определить реальный адрес первой ячейки сегмента ОП?
5. Используется ли дескриптор таблицы страниц при страничном управ- лении ОП?
178
7 Управление файлами
7.1 Виртуальная файловая система
7.1.1 Логические файлы
Файловая подсистема ОС предназначена для обслуживания процессов по информационному обмену с периферийными устройствами, прежде всего с устройствами ВП. В UNIXэта подсистема является частью ядра ОС
(см. п. 4.3) и имеет укрупненную структуру, приведенную на рисунке 7.1. Как видно из данного рисунка, файловая подсистема включает виртуальную файло- вую систему, программные части реальных файловых систем, а также кэш.
Рис. 7.1 Структура файловой подсистемы ОС
179
В п. 2.2 мы рассмотрели файлы и файловую структуру системы с точки зрения пользователя. Теперь расширим эти представления до уровня, использу- емого в программах процессов. Так как программисты являются частным слу- чаем пользователей, то такое расширение является вполне обоснованным.
Заметим, что программа процесса имеет дело не с реальным, а с логиче- ским файлом. В отличие от реального файла, представляющего собой уникаль- но поименованную битовую строку на конкретном носителе, логический файл не связан с конкретным носителем информации, а его программное имя не яв- ляется уникальным в пределах всей системы.
Несмотря на то что и физический, и соответствующий ему логический файл содержат одну и ту же битовую строку, разбиение этой строки на записи в обоих файлах различно. В то время как записи физического файла выбирают- ся исходя из удобства их размещения на носителе, разбиение логического фай- ла на записи производится по смысловому признаку. Например, если логиче- ский файл содержит сведения о сотрудниках какой-то организации, то одна запись такогофайла содержит информацию об одном сотруднике.
Многие прежние ОС поддерживали разбиение логических файлов на ло- гические записи. В результате программа могла, например, выполнить чтение или запись логической записи, используя для ее идентификации или номер за- писи в файле, или ее ключ (здесь ключ – символьное имя записи). Современные
ОС, в том числе UNIX, не поддерживают разбиение логических файлов на за- писи. Они позволяют программе работать с логическим файлом так, как с длинной последовательностью байтов. Естественно, что разбиение логического файла на записи есть. Но это разбиение известно только самой обрабатываю- щей программе. Для ОС оно не известно, и ее информационное общение с про- граммой сводится к обмену между ними цепочками байтов, которые ОС или помещает в файл, или считывает из него.
В п. 2.2 была рассмотрена файловая структура системы, объединяющая в единое целое все файлы системы. (Напомним, что для UNIX файловая струк- тура представляет собой единое дерево.) С учетом того что нигде в системе данная структура целиком не хранится, будем называть ее логической файловой
структурой. Если считать, что элементами логической файловой структуры являются логические файлы, то получим логическую файловую систему – пред- ставление совокупности файлов с точки зрения пользователя-программиста.
Заметим, что термин «файловая система» является общепринятым, но не однозначным. Точно так же принято называть совокупность подпрограмм, вы-
180 полняющих обработку соответствующих файлов. Во избежание путаницы бу- дем называть ту совокупность подпрограмм, которая выполняет обработку ло- гических файлов, виртуальной файловой системой (ФС).
После того как интерфейс системных вызовов выполнит «техническую» подготовку поступившего в ядро системного вызова, виртуальная ФС присту- пает к его действительному выполнению. Наличие этой подсистемы позволяет использовать в программах процессов стандартную совокупность системных вызовов для обработки файлов, не зависимую ни от физической реализации файлов, ни от физической реализации соответствующей файловой системы.
7.1.2 Открытие файла
Наиболее интересным системным вызовом, выполняемым виртуальной файловой системой, является открытие файла. Данный системный вызов вы- полняет связывание физического файла на ПУ с его логическим заменителем.
При этом для получения такой связи используются почти все управляющие структуры данных виртуальной файловой системы.
Для открытия существующего файла программа процесса должна содер- жать системный вызов:
ОТКРЫТЬ_ФАЙЛ (I
f
,r || i), (на Си – open), гдеI
f
– символьное имя файла одного из трех типов (простое, относительное или абсолютное), рассмотренных в п. 2.2. Это имя используется для идентификации физического файла, задавая его расположение в логи- ческой файловой структуре; r – требуемый режим работы с файлом (чтение, запись, чтение и запись, добавление в конец файла);
i
– программное имя (номер) файла, уникальное для данного процесса. Это имя логического файла, которое может использоваться далее програм- мой процесса для выполнения операций с этим файлом.
Получив данный системный вызов, виртуальная файловая система ищет требуемый файл, обращаясь за помощью к реальной файловой системе. По- дробно реальные файловые системы рассматриваются в п. 7.2, а пока лишь за- метим, что основной функцией такой системы является выполнение операций с физическими файлами. Кроме того, в данном разделе мы не будем обращать особого внимания на тот факт, что в любой ФС существует не одна, а несколь- ко реальных файловых систем. К этому вопросу мы вернемся в п. 7.3.
181
В зависимости от заданного символьного имени файла виртуальная ФС начинает поиск требуемого файла с анализа, или корневого каталога системы
(задано абсолютное имя файла), или корневого каталога данного пользователя
(относительное имя файла начинается с символа «»), или текущего каталога данного пользователя (простое или относительное имя файла). При этом имена текущего каталога и корневого каталога данного пользователя берутся из соот- ветствующих полей в структуре user, входящей в состав дескриптора процес- са (см. п. 5.2). В любом случае поиск искомого файла начинается с анализа того vnode
, который соответствует исходному каталогу.
Vnode (от virtual inode – виртуальный индексный дескриптор) – часть де- скриптора файла, содержащая ту информацию о реальном файле, состав кото- рой универсален для любого типа файлов. Перечислим наиболее интересные поля vnode:
1) число ссылок на данный vnode. Это суммарное число открытий фай- ла во всех процессах на данный момент времени;
2) указатель на тот элемент списка монтирования (рассматривается в п. 7.3), который соответствует реальной файловой системе, содер- жащей искомый физический файл;
3) указатель на тот элемент списка монтирования, который соответству- ет подключенной реальной ФС (если vnode соответствует каталогу, который является точкой монтирования);
4) номер реального дескриптора файла – inode. Подробно inode рас- сматриваются в п. 7.2, а пока лишь заметим, что это вторая часть де- скриптора файла (первая – vnode) и что в любой информационной части реальной ФС все inode пронумерованы. Номер inode являет- ся уникальным числом в пределах данной информационной части ре- альной ФС;
5) указатель на inode в таблице активных inode, расположенной в
ОП. Эта таблица принадлежит реальной ФС и содержит только те inode
, которые соответствуют файлам, открытым хотя бы в одном процессе;
6) указатель на перечень операций, который может выполняться над данным vnode. Состав этих операций стандартный. Но фактическая реализация каждой такой операции зависит от типа реальной ФС, в которой находится соответствующий физический файл. Поэтому
182 данное поле содержит указатель на массив других указателей, каждый из которых представляет собой начальный адрес той процедуры ре- альной ФС, которая выполняет соответствующую операцию над фи- зическим файлом;
7) тип файла, которому соответствует данный vnode: обычный файл, каталог, специальный файл устройства, символическая связь, удален- ный файл.
Обратим внимание на поле 2, содержащее указатель на реальную ФС в списке монтирования, и поле 4, содержащее номер inodeв реальной ФС.
Пара этих чисел является уникальным системным именем файла на данный момент времени. Другим уникальным системным именем файла является номер самого vnode в таблице vnode (рис. 7.2). Размер этой таблицы определяет максимальное число файлов, которые могут быть открыты в системе. При этом каждому открытому файлу соответствует один vnode, независимо от того, в скольких процессах сколько раз был открыт данный файл. Данное имя файла обеспечивает быстрый доступ к содержимому vnode файла, но оно является временным: после того, как файл будет закрыт во всех процессах, соответству- ющий vnode будет освобожден и может быть выделен другому файлу. В отли- чие от него рассмотренное ранее системное имя файла (указатель на реальную
ФС в списке монтирования и номер inode) является более долговременным и может использоваться для идентификации файла до тех пор, пока данная ре- альная ФС (информационная часть) не будет отсоединена от файловой структу- ры системы.
Определив из vnode исходного каталога его системное имя (указатель на реальную ФС в списке монтирования и номер inode), виртуальная ФС ис- пользует это системное имя каталога, а также символьное имя искомого файла в качестве входных параметров при вызове процедуры реальной ФС. Эта про- цедура выполняет трансляцию имени файла – получение на основе символьно- го имени файла его системного имени (указатель на реальную ФС в списке монтирования и номер inode). Заметим, что это одна из тех процедур реаль- ной ФС, доступ к которой выполняется с помощью указателя на перечень опе- раций, расположенного в поле vnode. Сама трансляция имени сводится к по- шаговому «движению» по цепочке каталогов до тех пор, пока или не будет достигнут требуемый файл, или при прохождении очередного каталога будет выяснено, что права доступа к нему данного пользователя не отвечают мини-
183 мально необходимым требованиям (см. п. 4.2). Так как каталог является разно- видностью файла, то для его просмотра также требуется выполнить операцию
«открытие файла». Но в отличие от открытия обычного файла открытие катало- га выполняется в рамках ядра и скрыто от прикладной программы, выдавшей системный запрос.
Рис. 7.2 Системные структуры данных для доступа процессов к файлам
184
Если при чтении последнего каталога, заданного в символьном имени файла, будет найдено искомое простое имя файла, то процедура трансляции имени возвратит в виртуальную ФС системное имя файла (указатель на реаль- ную ФС в списке монтирования и номер inode). Далее виртуальная ФС ис- пользует это системное имя файла для поиска его vnode в своей таблице.
Если требуемый vnode обнаружен, то число ссылок в его соответствую- щем поле увеличивается на единицу. Если виртуальная ФС не обнаружила vnode открываемого файла в своей таблице, то она создает новый vnode. Для этого ищется первый свободный элемент в таблице vnode, и его порядковый номер становится номером нового vnode. При заполнении полей этого vnode виртуальная ФС использует информацию, возвращенную ей процедурой реаль- ной ФС.
После того как vnode открываемого файла или найден, или создан зано- во, виртуальная ФС добавляет новую запись в свою системную файловую таб-
лицу. Каждый процесс имеет в этой таблице свои записи, каждая из которых со- ответствует одному открытому процессом файлу. Если один и тот же файл открыт процессом несколько раз, то каждому открытию соответствует своя за- пись в системной файловой таблице. Перечислим поля этой записи:
1) режим доступа к файлу (чтение, запись, чтение и запись, добавление в конец файла);
2) текущее значение файлового указателя – номер байта файла, начиная с которого будет выполняться следующая операция информационного обмена с файлом (чтение или запись). Сразу после открытия файла эта переменная указывает в зависимости от режима открытия на самый первый или самый последний байт файла;
3) указатель на vnode файла.
Далее виртуальная ФС находит первую свободную строку в таблице от-
крытых файлов процесса, являющейся частью структуры user процесса, а за- тем заполняет эту строку. Данная строка имеет всего два поля: указатель на со- ответствующую строку в системной файловой таблице и флаг наследования
открытого файла. Если этот флаг установлен, то при создании дочернего про- цесса (с помощью соответствующего системного вызова) данный файл закры- вается и его номер не наследуется дочерним процессом.
После того как строка в таблице открытых файлов процесса заполнена, ее номер i возвращается системным вызовом в прикладную программу процесса в
185 качестве программного имени открытого файла. Это имя действует в пределах данного процесса, а также наследуется (если это не запрещено флагом наследо- вания) его дочерними процессами.
Использование для открытия файла строки таблицы открытых файлов процесса с наименьшим номером нашло применение, в частности, для перена- правления ввода-вывода. Например, если пользователь запустил с командной строки какую-то программу, указав при этом замену стандартного вывода (то есть экрана) на какой-то файл, то процесс-shell, выполняющий обработку этой команды, во-первых, закроет файл с программным именем 0. Во-вторых, он откроет заданный файл. При открытии файла будет выбран свободный эле- мент таблицы открытых файлов процесса с наименьшим номером, то есть с но- мером 0. Так как структура user, включающая таблицу открытых файлов про- цесса, наследуется дочерним процессом, то весь его вывод на экран будет записан в требуемый файл. Естественно, что процесс-shell после запуска но- вого процесса должен «восстановить справедливость», закрыв файл и открыв экран. Заметим, что многие файлы, которые shell открывает для себя, не предназначены для использования в дочерних процессах. Для таких файлов выполняется установка флага наследования.
На рисунке 7.2 один и тот же файл U открыт и в процессе 1, и в процес- се 2. Причем в процессе 1 он открыт дважды: под именем 1 и под именем 3.
1 ... 13 14 15 16 17 18 19 20 ... 23
175
В-третьих, если в ходе выполнения процесса ему понадобится дополни- тельная ОП, то запрашиваемый объем будет выделен ОС из подходящей сво- бодной области ЛВП динамически.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Всякое назначение памяти процессу, осуществляемое в ходе
его выполнения, называется динамическим распределением па-
мяти. Статическое распределение – память выделяется при со-
здании процесса.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
В-четвертых, ОС выполняет «загрузку» сегментов процесса в ЛВП путем записи начального линейного виртуального адреса каждого сегмента в его де- скриптор. При этом сегменты ядра (их дескрипторы находятся в GDT) всегда
«загружены» в ЛВП по одним и тем же адресам.
В-пятых, содержимое ЛВП используется ОС для выполнения записей в каталог таблиц страниц и в сами таблицы страниц (инициализация таблиц).
Один каталог страниц обычно используется для адресации памяти одного про- цесса. При этом из 1 024 строк каталога 256 строк соответствуют ОС, а 768 строк – прикладной программе. (При смене на ЦП выполняемого процес- са 256 строк в каталоге не меняются, а заменяются лишь 768 строк.) Если
4 Мбайта ЛВП, соответствующие данной строке каталога, содержат какую-то информацию, то в эту строку ОС помещает указатель на соответствующую таб- лицу страниц. Иначе – строка каталога содержит пустой указатель.
Таблица страниц, соответствующая непустой строке каталога, может со- держать до 1 024 строк, каждая из которых содержит дескриптор одной логиче- ской страницы программы. Так как объем одной страницы составляет
4 096 байтов, то максимальный объем ЛВП, соответствующий одной таблице страниц, составляет 4 Мбайта. Любая часть этого объема может соответство- вать «пустым» страницам. Так как ОС ведет учет распределения ЛВП, то «пу- стые» страницы ей известны, и она не создает для них дескрипторы в таблице страниц.
Естественно, что при создании процесса ОС распределяет ему не только
ЛВП, но и реальную ОП. Не предоставив процессу хотя бы небольшое число физических страниц, нельзя обеспечить его выполнение. При этом системная часть программы процесса (256 строк в каталоге таблиц страниц) всегда отоб- ражается на одну и ту же часть реальной ОП (с меньшими адресами). А при- кладная часть ЛВП отображается на ту совокупность физических страниц, ко-
176 торые ОС выделила процессу. Страничное распределение ОП обладает тем су- щественным достоинством, что вследствие одинаковой длины страниц любая логическая страница может быть загружена в любую физическую страницу.
Поэтому не только страницы процесса, но и страницы логического сегмента не образуют непрерывный раздел ОП, а располагаются в произвольных местах памяти.
Благодаря свопингу страниц число логических страниц процесса может быть значительно больше, чем выделенное ему число физических страниц. Для организации такого свопинга аппаратура процессора i80386 предоставляет в помощь ОС исключение отказ страницы, а также специальные биты в де- скрипторах страниц, аналогичные соответствующим битам в дескрипторе таб- лицы страниц (см. рис. 6.7):
1) P – бит присутствия страницы в памяти (1 – страница в ОП; 0 – нет);
2) бит D – устанавливается в 1, если была выполнена запись в страницу;
3) AVL – три бита, которые ОС может использовать по своему усмотре- нию.
Совместная работа аппаратуры и ядра ОС при реализации страничного свопинга заключается в следующем. Выполнив разделение очередного вирту- ального линейного адреса, аппаратура ЦП проверяет бит P в искомом дескрип- торе страницы. Если
P 1
, то выполнение программы продолжается, иначе – возникает исключение «отказ страницы». Его обработчик подкачивает требуе- мую страницу из ВП.
Обычно страница загружается на место ранее загруженной страницы, ко- торая или копируется из ОП на диск (если бит
D 1
), или нет (бит
D 0
). Для определения откачиваемой страницы могут использоваться различные крите- рии. Например, в качестве такой страницы может быть выбрана та, к которой было сделано наименьшее число обращений. В качестве счетчика числа обра- щений может быть использовано поле AVL дескриптора страницы.
Распределение ОП, основанное на страничном свопинге, обладает тем существенным достоинством по сравнению с сегментным свопингом, что вследствие одинаковой длины страниц размещение одной страницы в ОП мо- жет быть выполнено вместо любой другой. Поэтому при размещении в памяти новой страницы не требуется выполнять каких-либо перемещений ранее загру- женных страниц.
Что касается защиты информации в ОП, то аппаратура управления стра- ницами в i80386 предоставляет для этого единственное средство: при выполне-
177 нии любой машинной команды, выполняющей запись в ОП, аппаратно прове- ряется бит W в дескрипторе той страницы, в которую выполняется запись. При
W 1 команда записи производится, а при
W 0 возникает исключение. Эффек- тивность данного средства существенно ниже защитных действий, выполняе- мых аппаратурой управления сегментами (см. пп. 6.2.3).
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Контрольные вопросы по главе 6
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
1. Используется ли регистр CS для защиты информации в ОП?
2. Используется ли дескриптор сегмента процесса для защиты информа- ции в ОП?
3. Используется ли регистр EAX для защиты информации в ОП?
4. Как определить реальный адрес первой ячейки сегмента ОП?
5. Используется ли дескриптор таблицы страниц при страничном управ- лении ОП?
178
7 Управление файлами
7.1 Виртуальная файловая система
7.1.1 Логические файлы
Файловая подсистема ОС предназначена для обслуживания процессов по информационному обмену с периферийными устройствами, прежде всего с устройствами ВП. В UNIXэта подсистема является частью ядра ОС
(см. п. 4.3) и имеет укрупненную структуру, приведенную на рисунке 7.1. Как видно из данного рисунка, файловая подсистема включает виртуальную файло- вую систему, программные части реальных файловых систем, а также кэш.
Рис. 7.1 Структура файловой подсистемы ОС
179
В п. 2.2 мы рассмотрели файлы и файловую структуру системы с точки зрения пользователя. Теперь расширим эти представления до уровня, использу- емого в программах процессов. Так как программисты являются частным слу- чаем пользователей, то такое расширение является вполне обоснованным.
Заметим, что программа процесса имеет дело не с реальным, а с логиче- ским файлом. В отличие от реального файла, представляющего собой уникаль- но поименованную битовую строку на конкретном носителе, логический файл не связан с конкретным носителем информации, а его программное имя не яв- ляется уникальным в пределах всей системы.
Несмотря на то что и физический, и соответствующий ему логический файл содержат одну и ту же битовую строку, разбиение этой строки на записи в обоих файлах различно. В то время как записи физического файла выбирают- ся исходя из удобства их размещения на носителе, разбиение логического фай- ла на записи производится по смысловому признаку. Например, если логиче- ский файл содержит сведения о сотрудниках какой-то организации, то одна запись такогофайла содержит информацию об одном сотруднике.
Многие прежние ОС поддерживали разбиение логических файлов на ло- гические записи. В результате программа могла, например, выполнить чтение или запись логической записи, используя для ее идентификации или номер за- писи в файле, или ее ключ (здесь ключ – символьное имя записи). Современные
ОС, в том числе UNIX, не поддерживают разбиение логических файлов на за- писи. Они позволяют программе работать с логическим файлом так, как с длинной последовательностью байтов. Естественно, что разбиение логического файла на записи есть. Но это разбиение известно только самой обрабатываю- щей программе. Для ОС оно не известно, и ее информационное общение с про- граммой сводится к обмену между ними цепочками байтов, которые ОС или помещает в файл, или считывает из него.
В п. 2.2 была рассмотрена файловая структура системы, объединяющая в единое целое все файлы системы. (Напомним, что для UNIX файловая струк- тура представляет собой единое дерево.) С учетом того что нигде в системе данная структура целиком не хранится, будем называть ее логической файловой
структурой. Если считать, что элементами логической файловой структуры являются логические файлы, то получим логическую файловую систему – пред- ставление совокупности файлов с точки зрения пользователя-программиста.
Заметим, что термин «файловая система» является общепринятым, но не однозначным. Точно так же принято называть совокупность подпрограмм, вы-
180 полняющих обработку соответствующих файлов. Во избежание путаницы бу- дем называть ту совокупность подпрограмм, которая выполняет обработку ло- гических файлов, виртуальной файловой системой (ФС).
После того как интерфейс системных вызовов выполнит «техническую» подготовку поступившего в ядро системного вызова, виртуальная ФС присту- пает к его действительному выполнению. Наличие этой подсистемы позволяет использовать в программах процессов стандартную совокупность системных вызовов для обработки файлов, не зависимую ни от физической реализации файлов, ни от физической реализации соответствующей файловой системы.
7.1.2 Открытие файла
Наиболее интересным системным вызовом, выполняемым виртуальной файловой системой, является открытие файла. Данный системный вызов вы- полняет связывание физического файла на ПУ с его логическим заменителем.
При этом для получения такой связи используются почти все управляющие структуры данных виртуальной файловой системы.
Для открытия существующего файла программа процесса должна содер- жать системный вызов:
ОТКРЫТЬ_ФАЙЛ (I
f
,r || i), (на Си – open), гдеI
f
– символьное имя файла одного из трех типов (простое, относительное или абсолютное), рассмотренных в п. 2.2. Это имя используется для идентификации физического файла, задавая его расположение в логи- ческой файловой структуре; r – требуемый режим работы с файлом (чтение, запись, чтение и запись, добавление в конец файла);
i
– программное имя (номер) файла, уникальное для данного процесса. Это имя логического файла, которое может использоваться далее програм- мой процесса для выполнения операций с этим файлом.
Получив данный системный вызов, виртуальная файловая система ищет требуемый файл, обращаясь за помощью к реальной файловой системе. По- дробно реальные файловые системы рассматриваются в п. 7.2, а пока лишь за- метим, что основной функцией такой системы является выполнение операций с физическими файлами. Кроме того, в данном разделе мы не будем обращать особого внимания на тот факт, что в любой ФС существует не одна, а несколь- ко реальных файловых систем. К этому вопросу мы вернемся в п. 7.3.
181
В зависимости от заданного символьного имени файла виртуальная ФС начинает поиск требуемого файла с анализа, или корневого каталога системы
(задано абсолютное имя файла), или корневого каталога данного пользователя
(относительное имя файла начинается с символа «»), или текущего каталога данного пользователя (простое или относительное имя файла). При этом имена текущего каталога и корневого каталога данного пользователя берутся из соот- ветствующих полей в структуре user, входящей в состав дескриптора процес- са (см. п. 5.2). В любом случае поиск искомого файла начинается с анализа того vnode
, который соответствует исходному каталогу.
Vnode (от virtual inode – виртуальный индексный дескриптор) – часть де- скриптора файла, содержащая ту информацию о реальном файле, состав кото- рой универсален для любого типа файлов. Перечислим наиболее интересные поля vnode:
1) число ссылок на данный vnode. Это суммарное число открытий фай- ла во всех процессах на данный момент времени;
2) указатель на тот элемент списка монтирования (рассматривается в п. 7.3), который соответствует реальной файловой системе, содер- жащей искомый физический файл;
3) указатель на тот элемент списка монтирования, который соответству- ет подключенной реальной ФС (если vnode соответствует каталогу, который является точкой монтирования);
4) номер реального дескриптора файла – inode. Подробно inode рас- сматриваются в п. 7.2, а пока лишь заметим, что это вторая часть де- скриптора файла (первая – vnode) и что в любой информационной части реальной ФС все inode пронумерованы. Номер inode являет- ся уникальным числом в пределах данной информационной части ре- альной ФС;
5) указатель на inode в таблице активных inode, расположенной в
ОП. Эта таблица принадлежит реальной ФС и содержит только те inode
, которые соответствуют файлам, открытым хотя бы в одном процессе;
6) указатель на перечень операций, который может выполняться над данным vnode. Состав этих операций стандартный. Но фактическая реализация каждой такой операции зависит от типа реальной ФС, в которой находится соответствующий физический файл. Поэтому
182 данное поле содержит указатель на массив других указателей, каждый из которых представляет собой начальный адрес той процедуры ре- альной ФС, которая выполняет соответствующую операцию над фи- зическим файлом;
7) тип файла, которому соответствует данный vnode: обычный файл, каталог, специальный файл устройства, символическая связь, удален- ный файл.
Обратим внимание на поле 2, содержащее указатель на реальную ФС в списке монтирования, и поле 4, содержащее номер inodeв реальной ФС.
Пара этих чисел является уникальным системным именем файла на данный момент времени. Другим уникальным системным именем файла является номер самого vnode в таблице vnode (рис. 7.2). Размер этой таблицы определяет максимальное число файлов, которые могут быть открыты в системе. При этом каждому открытому файлу соответствует один vnode, независимо от того, в скольких процессах сколько раз был открыт данный файл. Данное имя файла обеспечивает быстрый доступ к содержимому vnode файла, но оно является временным: после того, как файл будет закрыт во всех процессах, соответству- ющий vnode будет освобожден и может быть выделен другому файлу. В отли- чие от него рассмотренное ранее системное имя файла (указатель на реальную
ФС в списке монтирования и номер inode) является более долговременным и может использоваться для идентификации файла до тех пор, пока данная ре- альная ФС (информационная часть) не будет отсоединена от файловой структу- ры системы.
Определив из vnode исходного каталога его системное имя (указатель на реальную ФС в списке монтирования и номер inode), виртуальная ФС ис- пользует это системное имя каталога, а также символьное имя искомого файла в качестве входных параметров при вызове процедуры реальной ФС. Эта про- цедура выполняет трансляцию имени файла – получение на основе символьно- го имени файла его системного имени (указатель на реальную ФС в списке монтирования и номер inode). Заметим, что это одна из тех процедур реаль- ной ФС, доступ к которой выполняется с помощью указателя на перечень опе- раций, расположенного в поле vnode. Сама трансляция имени сводится к по- шаговому «движению» по цепочке каталогов до тех пор, пока или не будет достигнут требуемый файл, или при прохождении очередного каталога будет выяснено, что права доступа к нему данного пользователя не отвечают мини-
183 мально необходимым требованиям (см. п. 4.2). Так как каталог является разно- видностью файла, то для его просмотра также требуется выполнить операцию
«открытие файла». Но в отличие от открытия обычного файла открытие катало- га выполняется в рамках ядра и скрыто от прикладной программы, выдавшей системный запрос.
Рис. 7.2 Системные структуры данных для доступа процессов к файлам
184
Если при чтении последнего каталога, заданного в символьном имени файла, будет найдено искомое простое имя файла, то процедура трансляции имени возвратит в виртуальную ФС системное имя файла (указатель на реаль- ную ФС в списке монтирования и номер inode). Далее виртуальная ФС ис- пользует это системное имя файла для поиска его vnode в своей таблице.
Если требуемый vnode обнаружен, то число ссылок в его соответствую- щем поле увеличивается на единицу. Если виртуальная ФС не обнаружила vnode открываемого файла в своей таблице, то она создает новый vnode. Для этого ищется первый свободный элемент в таблице vnode, и его порядковый номер становится номером нового vnode. При заполнении полей этого vnode виртуальная ФС использует информацию, возвращенную ей процедурой реаль- ной ФС.
После того как vnode открываемого файла или найден, или создан зано- во, виртуальная ФС добавляет новую запись в свою системную файловую таб-
лицу. Каждый процесс имеет в этой таблице свои записи, каждая из которых со- ответствует одному открытому процессом файлу. Если один и тот же файл открыт процессом несколько раз, то каждому открытию соответствует своя за- пись в системной файловой таблице. Перечислим поля этой записи:
1) режим доступа к файлу (чтение, запись, чтение и запись, добавление в конец файла);
2) текущее значение файлового указателя – номер байта файла, начиная с которого будет выполняться следующая операция информационного обмена с файлом (чтение или запись). Сразу после открытия файла эта переменная указывает в зависимости от режима открытия на самый первый или самый последний байт файла;
3) указатель на vnode файла.
Далее виртуальная ФС находит первую свободную строку в таблице от-
крытых файлов процесса, являющейся частью структуры user процесса, а за- тем заполняет эту строку. Данная строка имеет всего два поля: указатель на со- ответствующую строку в системной файловой таблице и флаг наследования
открытого файла. Если этот флаг установлен, то при создании дочернего про- цесса (с помощью соответствующего системного вызова) данный файл закры- вается и его номер не наследуется дочерним процессом.
После того как строка в таблице открытых файлов процесса заполнена, ее номер i возвращается системным вызовом в прикладную программу процесса в
185 качестве программного имени открытого файла. Это имя действует в пределах данного процесса, а также наследуется (если это не запрещено флагом наследо- вания) его дочерними процессами.
Использование для открытия файла строки таблицы открытых файлов процесса с наименьшим номером нашло применение, в частности, для перена- правления ввода-вывода. Например, если пользователь запустил с командной строки какую-то программу, указав при этом замену стандартного вывода (то есть экрана) на какой-то файл, то процесс-shell, выполняющий обработку этой команды, во-первых, закроет файл с программным именем 0. Во-вторых, он откроет заданный файл. При открытии файла будет выбран свободный эле- мент таблицы открытых файлов процесса с наименьшим номером, то есть с но- мером 0. Так как структура user, включающая таблицу открытых файлов про- цесса, наследуется дочерним процессом, то весь его вывод на экран будет записан в требуемый файл. Естественно, что процесс-shell после запуска но- вого процесса должен «восстановить справедливость», закрыв файл и открыв экран. Заметим, что многие файлы, которые shell открывает для себя, не предназначены для использования в дочерних процессах. Для таких файлов выполняется установка флага наследования.
На рисунке 7.2 один и тот же файл U открыт и в процессе 1, и в процес- се 2. Причем в процессе 1 он открыт дважды: под именем 1 и под именем 3.
1 ... 13 14 15 16 17 18 19 20 ... 23
7.1.3 Другие операции с файлами
1. Создание файла. Для создания нового файла любой процесс использует системный вызов:
СОЗДАТЬ_ФАЙЛ (I
f
, D || i), (на Си – creat), гдеI
f
– символьное имя файла;
D – задаваемые права доступа к файлу (права доступа были рассмотрены нами в п. 4.2);
i
– программное имя (номер) файла, уникальное для данного процесса.
Данный системный вызов не только создает новый файл, но и выполняет его открытие для записи, возвращая в качестве выходного параметра внутри- процессный номер файла. В качестве владельцев файла записываются владе- лец – пользователь и владелец-группа того процесса, который выдал данный системный вызов. Если файл с именемI
f уже существует, то его длина обнуля- ется, а его права доступа и владельцы остаются прежними.
186
Виртуальная файловая система начинает выполнение данного системного вызова с того, что определяет наличие файла с заданным именем I
f
. При этом поиск требуемого файла выполняется с помощью реальной файловой системы точно так же, как и при открытии файла. В результате поиска или определяется inode файла, или делается вывод об отсутствии файла с заданным именем.
В первом случае виртуальная файловая система выполняет обнуление длины файла (с помощью процедуры реальной файловой системы), а затем создает но- вый vnode в первой свободной строке своей таблицы vnode. После этого за- полняется строка в системной файловой таблице, а также заполняется строка в таблице открытых файлов процесса, являющейся частью его структуры user.
Номер этой строки возвращается в программу процесса в качестве программно- го имени файла i.
Если файл с заданным именем I
f не обнаружен, виртуальная файловая система приступает к его созданию. Для этого процедуры реальной файловой системы создают для нового файла inode и помещают указатель на этот inode в родительский каталог. Номер inode и указатель на него в таблице ак- тивныхinode возвращаются в виртуальную файловую систему, которая ис- пользует эти параметры для создания нового vnode. Затем создаются новые записи в системной файловой таблице и в таблице открытых файлов процесса.
2. Дублирование программного имени (номера). В результате выполнения данного системного вызова файл, открытый ранее программой процесса, полу- чает еще одно имя (номер). В отличие от повторного открытия файла старый и новый номера файла указывают на один и тот же логический файл. Это про- является, в частности, в существовании единственного файлового указателя.
Дублирование имени файла выполняет системный вызов:
ДУБЛИРОВАТЬ_НОМЕР_ФАЙЛА (i
1
|| i
2
), (на Си – dup), где i
1
– программное имя (номер) ранее открытого файла; i
2
– дополнительное программное имя файла.
При выполнении данного системного вызова виртуальная файловая си- стема создает новую запись в таблице открытых файлов процесса, но не создает новой записи в системной файловой таблице.
3. Перемещение файлового указателя. Эта операция выполняется для то- го, чтобы последующая операция чтения из файла или записи в него выполня- лась бы, начиная с требуемого байта файла.
Перемещение файлового указателя выполняет системный вызов:
187
УСТАНОВИТЬ_ФАЙЛОВЫЙ_УКАЗАТЕЛЬ (i, l, t || L), (на Си – lseek), гдеi – программный номер файла; l – требуемая величина смещения указателя;
t – тип смещения файлового указателя (0 – от текущего положения; 1 – от конца файла; 2 – от начала файла);
L
– полученное значение файлового указателя.
При выполнении данного системного вызова виртуальная ФС корректи- рует содержимое поля «текущее значение файлового указателя» в той строке системной файловой таблицы, на которую указывает указатель в i-й строке таблицы открытых файлов процесса.
Интересно отметить, что новое значение файлового указателя может вый- ти за пределы файла. В этом случае в файле образуется «дыра» – незаполненная последовательность байтов. В действительности содержимое «дыры» заполня- ется нулями.
4. Чтение из файла. Операция чтения начинает выполняться с того байта файла, номер которого содержит файловый указатель. После завершения опе- рации значение файлового указателя увеличивается на число считанных байтов.
Для выполнения чтения из файла используется системный вызов:
ЧТЕНИЕ_ИЗ_ФАЙЛА (i, n, A || N), (на Си – read), где i – программный номер файла; n – количество читаемых байтов;
A
– начальный адрес прикладной области в ОП, в которую производится чтение;
N – количество фактически считанных байтов.
При выполнении данного системного вызова виртуальная ФС считывает из i-й строки таблицы открытых файлов процесса указатель на строку в си- стемной файловой таблице, а затем читает из этой строки текущее значение файлового указателя. Кроме того, из этой же строки системной файловой таб- лицы считывается указатель на vnode, из которого, в свою очередь, считыва- ется указатель на inode. Этот указатель используется виртуальной ФС для за- дания физического файла при инициировании той процедуры реальной ФС, которая производит чтение из заданного физического файла с указанного места заданного числа байтов.
188 5. Запись в файл. Операция записи выполняется с того байта файла, номер которого содержит файловый указатель. После завершения операции значение файлового указателя увеличивается на число записанных байтов.
Для выполнения записи в файл используется системный вызов:
ЗАПИСЬ_В_ФАЙЛ (i, n, A ||), (на Си – write), где i – программный номер файла; n – количество записываемых байтов;
A
– начальный адрес прикладной области в ОП, из которой производится запись в файл.
Данный системный вызов выполняется виртуальной ФС совместно с ре- альной ФС аналогично тому, как выполняется чтение из файла.
6. Закрытие файла. Данная операция выполняет действия, обратные опе- рации открытия файла. При этом уничтожается логический файл с заданным программным номером, а соответствующий физический файл остается без из- менений.
Для выполнения закрытия файла используется системный вызов:
ЗАКРЫТЬ_ФАЙЛ (i ||), (на Си – close), гдеi – программный номер файла.
При выполнении данного системного вызова виртуальная ФС считывает из i-й строки таблицы открытых файлов процесса указатель на строку систем- ной файловой таблицы. После этого i-я строка таблицы открытых файлов про- цесса помечается как свободная. Далее из найденной строки системной файло- вой таблицы производится считывание указателя на vnode файла, после чего строка системной файловой таблицы также помечается как свободная.
Далее уменьшается на 1 содержимое поля vnode – «число ссылок на данный vnode». Если полученное число больше нуля, то выполнение данного системного вызова завершено. Иначе – виртуальная ФС освобождает vnode, предварительно считав из его поля указатель на строку в таблице активных inode
. Далее производится вызов той процедуры реальной ФС, которая по за- данному указателю на строку в таблице активных inodeосвобождает эту строку.
7. Уничтожение файла. Фактически результатом этой операции является уничтожение жесткой связи между физическим файлом и одним из каталогов.
Само уничтожение файла выполняется только в том случае, если уничтожаемая жесткая связь была единственной для данного файла.
189
Для уничтожения файла программа процесса использует системный вы- зов:
УНИЧТОЖИТЬ_ФАЙЛ (I
f
||), (на Си – unlink), гдеI
f
– символьное имя файла.
При выполнении данного системного вызова виртуальная ФС находит в своей таблице или создает новый vnode для родительского каталога по от- ношению к уничтожаемому файлу. Далее она вызывает процедуру реальной
ФС с целью выполнить корректировку этого каталога, передав на вход вызыва- емой процедуры указатель на соответствующий inode. Процедура реальной
ФС не только корректирует каталог, убрав из него информацию о файле, но и проверяет поле вinode, содержащее число оставшихся жестких связей с фай- лом. Если это число равно нулю, то производится фактическое уничтожение файла путем освобождения егоinode (на диске), а также освобождения зани- маемой этим файлом памяти диска.
8. Отображение файла на ОП. Применение данного системного вызова позволяет прикладной программе выполнять последующие операции с содер- жимым файла на устройстве ВП так, как выполняются действия над обыкно- венной областью ОП, не используя рассмотренные выше системные вызовы чтения из файла и записи в него.
Отображение заданного файла на область ОП выполняет системный вы- зов:
ОТОБРАЗИТЬ_ФАЙЛ (i, l, n, || A), (на Си – mmap), гдеi – программный номер файла. Для получения данного номера отображае- мый файл должен быть предварительно открыт в программе процесса; l – величина смещения в файле на диске; n – количество отображаемых байтов файла;
A
– начальный адрес прикладной области в ОП, на которую производится отображение файла.
Выполняя данный системный вызов, ФС выполняет округление величины n в большую сторону до ближайшей границы логической страницы. Далее вы- зывается подсистема управления памятью с целью выделения такой области в прикладной части линейного виртуального адресного пространства процесса, которая достаточна для размещения отображаемой части файла (с учетом округления длины). Напомним, что в данном случае речь идет не о выделении
190 реальной ОП, а лишь о создании таблицы страниц и записи в нее дескрипторов страниц.
Само же назначение реальной ОП (физической страницы) производится в результате страничного свопинга, реализация которого не зависит от того, что находится в странице ОП – фрагмент отображаемого файла или обычные дан- ные программы. Единственное отличие: при свопинге отображения файла ин- формационный обмен производится не с областью свопинга на системном устройстве ВП, а с тем дисковым файлом, отображение которого выполнено.
Следует добавить, что применение отображения файла не позволяет из- менить длину этого файла.
7.2 Реальные файловые системы
7.2.1 Критерии оценки файловых систем
Рассмотренная выше виртуальная ФС обеспечивает стандартный про- граммный интерфейс, но с реальными (физическими) файлами эта подсистема
ФС не работает. Эту функцию выполняет реальная ФС (программная часть).
Наличие уточнения в круглых скобках обусловлено тем, что используемый в литературе термин «реальная ФС» существенно неоднозначен. Далее будем называть программной частью реальной ФС совокупность подпрограмм ядра
ОС, предназначенных для выполнения действий над информационной частью реальной ФС. При этом под информационной частью реальной ФС будем по- нимать совокупность физических файлов, а также управляющих структур дан- ных, расположенных в непрерывной части носителя ВП, называемой в UNIX
разделом.
В отличие от программной части реальной ФС, существующей в системе
(в ядре) в единственном экземпляре, число информационных частей реальной
ФС может быть любым. Каждая такая часть предназначена для покрытия одно- го непрерывного фрагмента логической файловой структуры системы, распо- ложенного в разделе носителя ВП. Вопросы объединения реальных ФС (ин- формационных частей) в единую логическую структуру будут рассмотрены в п. 7.3, а пока будем рассматривать каждую такую ФС в качестве отдельной информационной структуры.
Любая UNIX-система поддерживает несколько типов реальных ФС. Вы- бор для конкретного носителя (а точнее – для раздела носителя) типа реальной
ФС зависит от требований, предъявляемых к ней пользователем. Каждое
191 из этих требований может рассматриваться в качестве одного из критериев вы- бора реальной ФС. Перечислим основные из этих критериев:
1) функциональность– пригодность реальной ФС выполнять те или иные функции. Например, различной функциональностью обладают распределенные и локальные реальные ФС. По этому же критерию различаются те реальные ФС, которые поддерживают наличие раз- личных прав доступа у разных пользователей и которые не поддержи- вают такое наличие;
2) производительность – средняя скорость информационного обмена с физическими файлами, принадлежащими реальной ФС;
3) надежность– способность реальной ФС выполнять свои функции в полном или частичном объеме после завершения воздействия на ВС факторов, не соответствующих требованиям нормальной эксплуата- ции системы. К таким факторам относятся сбои в ВС, например в ре- зультате внезапной потери питания системы, а также механические повреждения носителя ВП;
4) используемость ВП – отношение общей длины физических файлов, содержащихся в информационной части реальной ФС к объему соот- ветствующего раздела носителя;
5) предельная длина имени файла – максимальная длина простого имени файла;
6) предельное число файлов – максимальное количество физических файлов, которые могут находиться в одной информационной части реальной ФС;
7) сложность алгоритмов – сложность алгоритмов подпрограмм, при- надлежащих программной части реальной ФС.
При выборе реальной ФС, как и при выборе любой другой системы, набор критериев, используемых для оценки вариантов системы, является про- тиворечивым. Например, производительность многих типов реальных ФС зави- сит от используемости ВП: при высокой степени использования ВП производи- тельность реальной ФС существенно падает. Аналогично повышение надежности реальной ФС обычно связано с дублированием информации, хра- нящейся на носителе, что приводит к снижению реальной производительности системы и используемости ВП.
Интересно выполнить сравнение распределенной и локальной реальных
ФС. По критерию функциональности явно выигрывает распределенная ФС, так
192 как она позволяет своим информационным частям размещаться на удаленных
ЭВМ. Но по критериям надежности, сложности алгоритмов и особенно по кри- терию производительности локальная реальная ФС явно предпочтительней. Так как логика использования распределенной реальной ФС имеет некоторые отли- чия от логики работы распределенной (сетевой) ОС, рассмотренной в п. 4.4, в п. 7.3 мы вернемся к рассмотрению распределенной реальной ФС.
При создании реальной ФС ее проектировщики находят в процессе про- ектирования некоторый компромисс между предъявляемыми к ней требовани- ями. Иными словами, оценки разрабатываемого варианта системы по перечис- ленным выше критериям должны быть, с точки зрения ее разработчиков, оптимальными. Здесь термин «оптимальный» существенно отличается от соот- ветствующего понятия в математике, которое предполагает поиск наилучшего решения лишь по одному критерию, а остальные критерии, как правило, запи- сываются в качестве ограничений математической модели.
Задача выбора реальной ФС пользователем системы может рассматри- ваться как упрощенный вариант задачи проектирования. Поэтому при решении этой задачи должны быть известны хотя бы приближенные оценки сравнивае- мых типов реальных систем по перечисленным выше критериям. С учетом то- го, что общее количество реальных ФС, поддерживаемых в настоящее время различными UNIX-системами, достаточно велико, в настоящем пособии не ста- вится задача рассмотрения всех этих реальных ФС. Вместо этого далее рас- сматриваются некоторые принципы, используемые при создании таких систем, позволяющие существенно улучшить их оценки по основным критериям из пе- речисленных выше.
При изложении принципов проектирования реальных ФС далее рассмат- риваются три типа таких систем: s5fs, ffsи fat. Первые две из этих систем являются для UNIX «родными». Несмотря на то что эти ФС, особенно s5fs, разработаны давно, они до сих пор поддерживаются многими UNIX-системами.
Присущая этим ФС простота делает их удобными для нашего рассмотрения.
Третья из перечисленных реальных ФС (fat) является для UNIX «чу- жой», так как она разрабатывалась для операционных систем MS-DOS и Win- dows. Но учитывая ее очень широкое распространение, она входит в состав ре- альных ФС, поддерживаемых UNIX. Обратим внимание, что только информационные части fat-систем, принадлежащих UNIX, аналогичны ин- формационным частям таких систем, принадлежащих MS-DOS и Windows. Что касается программных частей, то эти части реальной ФС сильно различаются в