Ю. Вахалия - UNIX изнутри (2003) (1114670), страница 88
Текст из файла (страница 88)
Следовательно, ядро блокирует чпог)е перед началом выполнения геаг1 или чгп1е и освобождает объект после завершения ввода-вывода. В системе ВЪ'К4 блокировка и освобождение производятся при помощи операций ЧОР йМОСК и ЧОР КЧ10йСОСК. После этого система вызывает функцию ЧОР ВЕАО или ЧОР ЧЧВ1ТЕ для выпол- 874 Глава 8. Базовые элементы и интерфейс файловой системы пения действий, зависящих от конкретной файловой системы. Большая часть этих действий производится на зависимом от файловой системы уровне.
Более подробно о них вы прочтете в разделах 9.3.3 (для з5Ь) и 10.6.3 (для НЕЯ). В системе ЯЪ'К4 операции ввода-вывода файлов схожи с обработкой подсистемы виртуальной памяти, что будет обсуждаться позже, в разделе 14.8. 8.10.6. Атрибуты файлов Для изменения или запроса специфических атрибутов файлов, таких как идентификатор владельца или права (см.
раздел 8.2.2), существует несколько различных системных вызовов. В ранних версиях П)ч1Х такие вызовы производили прямое чтение или запись в поля индексного дескриптора, хранящегося в памяти. Если было необходимо, атрибуты копировались в дескриптор, находившийся на диске. Действия функций сильно зависели от конкретной реализации системы. Так как архитектура чпоое/ч(з поддерживает большое количество типов файловых систем, каждя из которых может иметь различные методы хранения структур метаданных в памяти или на диске, то можно сказать, что она предлагает общий интерфейс взаимодействия. Для чтения и записи атрибутов файла применяются операции чОР БсТАП8 и ЧОР 58ТАТТ8, при этом используется независимый от файловой системы объект под названием чай1п Хотя эта структура и содержит информацию, идентичную с содержимым индексного дескриптора з5Ь или пЬ, ее формат является более общим и не зависит от какой-либо одной файловой системы.
Это дает возможность специфическими реализациям преобразовывать информацию между общей структурой и собственными структурами метаданных, 8.10.7. Права пользователя Некоторым системным файловым операциям необходимо проверять наличие права пользователя на доступ к файлу в выбранном режиме.
Управление доступом производится путем проверки идентификаторов группы и пользователя, вызвавшего функцию. Перечисленные идентификаторы обычно хранятся в области ц вызывающего процесса. В современных системах Т)1ч'1Х такая информация собрана в мандате (сгег1еп11а1з) (структура стеб), который передается принудительно (через указатель) большинству файловых операций. Каждый процесс обладает мандатом, статично размещенным в области в или структуре ргос. Для проведения операций над локальными файлами мы передаем указатель на этот объект, что не отличается от трактовки прямой передачи информации из области и, принятой в более ранних версиях системы.
Преимуществом нового подхода является поддержка удаленных файловых операций, которые выполняются серверными процессами по запросу клиентов. Следовательно, в этом случае полномочия определяются правами клиента, а не процесса на сервере. Таким образом, сервер может динамиче- 8.11. Анализ 375 ски размещать структуры прав для каждого запроса клиента и инициализировать их в зависимости от его идентификаторов пользователя и группы. Так как права могут передаваться от одной операции к другой н должны поддерживаться до завершения действий, ядро ассоциирует с каждым мандатом счетчик ссылок, освобождая структуру, если его значение станет равным нулю, 8.11. Анализ гьй Оригинальная файловая система Зуыегп У Вегхе)еу Еав1 Е()е Зуз1егп (быстрая файловая система), адаптированная для поддержки интерфейса у(в/упос1е гг5 Журнальная файловая система Уегйав, обладающая несколькими дополнительными возможностями Файловая система для специальных файлов устройств Ь)еввог(г Е)1е Зуз1егл (сетевая файловая система) гресн Н'г5 ((г5 Непго1е Ейе Зпаг)пр Ейе Зув1егп (система разделения удаленных файлов) Ион Система для файлов Е)ЕО («первым зашел, первым вышел») /ргос Файловая система, в которой каждый процесс представлен в виде файла Ыг Воо1 Е)(е Зузгегп (загрувочная файловая СиСтЕма) Многие варианты (.))т)1Х, например Яо)аггз, дополнительно поддерживают файловую систему ГАТ МЯ-РОЯ.
Такая возможность позволяет обмениваться данными между машинами Т)ОЯ и ПчЦХ при помощи гибких дисков. Более подробно о файловых системах вы прочтете в следующих главах книги. Архитектура упог)е/УЬ, представленная в системе ЯцпОБ, получила в дальнейшем широкое распространение. Однако при ее рассмотрении необходимо поговорить и о недостатках, а также посмотреть, как они были исправлены в других вариантах системы (.))т)!Х. Большинство проблем архитектуры происходит от применяемого метода преобразования полных имен. Рассмотрению проблем упог(е/УЬ и их решению в современных реализациях (Лч)1Х будет посвящена оставшаяся часть главы. Интерфейс упог)е/УЬ представляет мощную архитектуру программирования.
Он позволяет сосуществовать в одной ОС сразу нескольким файловым системам. Производители ОС имеют возможность добавлять новые файловые системы в ядро в виде модулей. Базовые элементы, построенные на объектноориентированном подходе, эффективно разграничивают файловую систему от остальной части ядра. Это способствовало развитию нескольких интересных реализаций файловых систем. При установке ЯЧМ в типовом комплекте поддерживаются следующие типы файловых систем: 376 Глава 8. Базовые элементы и интерфейс файловой системы 8.11.1.
Недостатки реализации в системе ЗЧВ4 Одной из главных проблем, влияющих на производительность системы, является работа функции 1ооЕцррлО, просматривающей только один компонент за раз. При этом для каждого компонента вызывается зависимая от файловой системы функция ЧОР ЕООКОР. Такой подход не только приводит к чрезмер. ным перегрузкам, но и в случае применения для удаленных файловых систем требует большого объема взаимодействий между клиентом и сервером.
Этот метод был выбран компанией Вцп в первую очередь из соображений поддержки ее )Чегтчогк ЕВ1е Яузгеш (ЫРЯ), где процедура поиска ограничена одним компонентом за один проход. Так как это не является жизненно важным для удаленных файловых систем, оптимальным решением будет предоставление выбора просматриваемой части имени файла за один прием каждой файловой системе по отдельности. Вторая проблема возникает из-за того, что операция подстановки имен не сохраняет информацию о состоянии по причине самой природы протокола ЫРВ.
Поскольку операция не блокирует родительский каталог, не существует гарантии правильности полученного результата через любой промежуток времени. Приведем пример возникновения такой ситуации. Представьте, что пользователь вводит запрос на создание файла /а/в. Операция создания занимает два этапа. Сначала ядро производит просмотр имен для определения, не существует ли уже файл с таким именем. Если такой файл не обнаружен, ядро создает его при помощи функции ЧОР ЕйЕАТЕ с параметром объекта чпог)е для /а.
Проблемным является временной промежуток между возвратом функции подстановки (с результатом ЕМОЕМТ) и вызовом функции создания файла, так как в это время каталог /а не блокиру. ется. Следовательно, любой другой процесс может создать в нем файл с тем же именем. Для корректности можно заставить операцию ЧОР СКЕАТЕ просматривать каталог заново, однако это приведет к дополнительной загрузке системы.
Одним из методов избавления от дополнительных ненужных действий является изменение работы функции преобразования, которая не станет транслировать последний компонент в том случае, если после ее запуска будет вызвана операция сгеа1е или де1е1е. Это уменьшает модульность интерфейса, так как операции не зависят друг от друга. Существуют иные варианты реализации поддержки нескольких файловых систем в (ТХ1Х.
Каждый из них основан на концепции существования единого интерфейса, реализованного по-своему конкретными файловыми системами. Различия между ними происходят от различных целей, поставленных перед разработчиками, расхождений в базовых операционных системах, а также от специфики файловых систем, для поддержки которых создается новый интерфейс. Одними из самых ранних альтернатив явились системы 8.11. Анализ 377 717е лузГет звяусл в ОС 8ЧВ3 11Ы1Х корпорации АТЛЕТ 1121 и яепепсЯе эузкет (8Ь) в системе 1Л.ТИХ 1131. Обе архитектуры сохранили концепцию применения индексного дескриптора как базового объекта, представляющего файл, но разделили его на зависящую и независящую от файловой системы части.