Организация файловой системы

ВВЕДЕНИЕ

Все компьютерные приложения должны хранить и извлекать информацию. Запущенный процесс в собственном адресном пространстве может хранить только ограниченный объем данных. Но емкость хранилища ограничена размером виртуального адресного пространства. Для такого объема вполне достаточно ряда приложений, но есть и приложения, например, системы бронирования авиабилетов, банковские или корпоративные системы учета, для которых этого явно недостаточно.
Вторая проблема с хранением информации в адресном пространстве процессов заключается в том, что при завершении процесса эта информация теряется. Для многих приложений (таких как базы данных) информация должна храниться в течение недель, месяцев или даже бесконечно долго. Его исчезновение с окончанием процесса абсолютно недопустимо. Более того, его не следует терять, даже если процесс выйдет из строя в случае сбоя компьютера.
Третья проблема заключается в том, что часто бывает необходимо обеспечить одновременный доступ к некоторой информации (или ее части) для нескольких процессов. Если онлайн-телефонный справочник хранится в адресном пространстве только одного процесса, то только этот процесс может получить к нему доступ. Эта проблема решается за счет того, что информация как таковая не зависит от каких-либо процессов.
Таким образом, есть три основных требования к долговременному хранилищу информации:
1. Оно должно предоставлять возможность хранения огромного количества информации.
2. Информация должна пережить прекращение работы использующего ее процесса.
3. К информации должны иметь одновременный доступ несколько процессов
Файлы логические информационные блоки, создаваемые процессами. Диск обычно содержит тысячи или даже миллионы файлов, которые не зависят друг от друга. Фактически, если мы рассматриваем каждый файл как некое адресное пространство, то это будет довольно близко к истине, за исключением того, что файлы используются для имитации диска, а не RAM.
Процессы могут читать существующие файлы и при необходимости создавать новые. Информация, хранящаяся в файлах, должна быть долговечной, то есть на нее не должно влиять создание процесса и его завершение. Файл должен прекратить свое существование только в том случае, если его владелец явно удалит его.
Операционная система управляет файлами. Структура файлов, их имена, доступ к ним, их использование, защита, реализация и управление - основные вопросы при разработке операционных систем. В общем, часть операционной системы, обрабатывающая файлы.
С точки зрения пользователя, наиболее важным аспектом файловой системы является ее представление, то есть, что это за файл, как файлы названы, какая у них защита, какие операции разрешено выполнять с файлами. , так далее.
 
ОСНОВНАЯ ЧАСТЬ

Файлы

Имена файлов

Многие операционные системы поддерживают имена файлов, состоящие из двух частей, разделенных точкой, как, например, prog.c. Часть имени, следующая за точкой, называется расширением имени файла и, как правило, несет некоторую информацию о файле. Например, в MS-DOS имена файлов состоят из 1–8 символов и имеют (необязательно) расширение, состоящее из 1–3 символов. В UNIX количество расширений выбирает сам пользователь, так что имя файла может иметь два и более расширений, например homepage.html.zip, где .html указывает на наличие веб-страницы в коде HTML, а .zip — на то, что этот файл (homepage.html) был сжат архиватором. Некоторые распространенные расширения и их значения показаны на рисунке. 1.

Рисунок 1 - некоторые типичные расширения имен файлов
Структура файла

Файлы можно структурировать по-разному. На рисунке 2 показаны три наиболее вероятные структуры.

Рисунок 2 - три типа файлов: а — последовательность байтов; б — последовательность записей; в — дерево
Когда операционная система считает файлы не более чем последовательностью байтов, она обеспечивает максимальную гибкость. Пользовательские программы могут помещать в свои файлы все, что они хотят, и называть их как угодно рисунок 2.а.
Первый шаг к решению показан на рис. 2.b. В этой модели файл представляет собой последовательность записей фиксированной длины, каждая из которых имеет свою внутреннюю структуру. Основная идея файла как последовательности записей заключается в том, что операция чтения возвращает одну из записей, а операция записи перезаписывает или дополняет одну из записей.
Третий тип файловой структуры показан на рис. 2.c. При такой организации файл состоит из дерева записей, не обязательно одинаковой длины, каждая из которых содержит ключевое поле в определенной позиции. Дерево отсортировано по ключевому полю, что позволяет быстрее найти конкретный ключ.
Здесь основная операция — это не получение «следующей» записи, хотя эта операция тоже возможна, а получение записи с указанным ключом. Для файла зоопарка рис. 2.c, вы можете, например, попросить систему вернуть запись с помощью ключа, совершенно не заботясь о ее конкретной позиции в файле. Более того, в файл могут быть добавлены новые записи, и операционная система, а не пользователь, решает, где их разместить.

Типы файлов

Многие операционные системы поддерживают несколько типов файлов. Например, в системах UNIX (опять же, включая OS X) и Windows есть обычные файлы и каталоги. UNIX также предоставляет символьные и блочные специальные файлы. Файлы, содержащие информацию о пользователе, считаются нормальными. Все файлы на рис. 2 являются общими. Каталоги — это системные файлы, предназначенные для поддержки структуры файловой системы. Специальные символьные файлы связаны с вводом-выводом и используются для моделирования устройств последовательного ввода-вывода, таких как терминалы, принтеры и сети. Блочные специальные файлы используются для имитации дисков.
Обычные файлы — это файлы ASCII или двоичные файлы. Файлы ASCII состоят из текстовых строк. Файлы ASCII состоят из текстовых строк. В некоторых системах каждая строка заканчивается символом возврата каретки. В других системах используется символ перевода строки. Некоторые системы (например, Windows) используют оба символа. Строки не обязательно должны быть одинаковой длины. Большим преимуществом файлов ASCII является возможность отображать и распечатывать их как есть, и их можно редактировать с помощью любого текстового редактора. Все остальные файлы являются двоичными, что означает, что они не являются файлами ASCII. Их распечатка будет содержать непонятный и бесполезный набор символов. Обычно они имеют какую-то внутреннюю структуру, известную программе, которая их использует.
Например, на рис. 3.a показан простой исполняемый двоичный файл, взятый из одной из самых ранних версий UNIX. Файл состоит из пяти разделов: заголовка, текста, данных, битов перемещения и таблицы символов. Заголовок начинается с так называемого магического числа, которое идентифицирует файл как исполняемый (чтобы предотвратить случайное выполнение файла, не соответствует этому формату). Далее следуют размеры различных частей файла, адрес, с которого он начинает выполнение, и количество битов флага. За заголовком следует текст программы и данные. Они загружаются в ОЗУ и перемещаются с помощью битов перемещения. Таблица символов используется для отладки. Второй пример двоичного файла — это архив, также взятый из UNIX (рисунок 3.b). Он состоит из набора скомпилированных, но не связанных библиотечных подпрограмм (модулей). Каждому модулю предшествует заголовок, информирующий о его названии, дате создания, владельце, защитном коде и размере. Как и в исполняемом файле, заголовки модулей заполнены двоичными числами.

Рисунок 3 - структур двоичных файлов: а - исполняемый файл; б – архив

Доступ к файлам

Самые ранние операционные системы обеспечивали только один тип доступа к файлам - последовательный. В этих системах процесс мог читать все байты или записи файлов только по порядку с самого начала, но не мог перепрыгнуть и прочитать их не по порядку. Но последовательные файлы можно было перемотать, чтобы прочитать их по мере необходимости. Эти файлы были полезны в те дни, когда в качестве носителя использовалась магнитная лента.
Когда для хранения файлов стали использоваться диски, появилась возможность читать байты или записывать файлы в неупорядоченном порядке или получать доступ к записям по ключу, а не по позиции. Файлы, в которых байты или записи могут быть прочитаны в любом порядке, стали известны как файлы с произвольным доступом. Они востребованы многими приложениями.
Файлы с произвольным доступом являются неотъемлемой частью многих приложений, например систем управления базами данных. Если пассажир бронирует место на конкретный рейс, программа бронирования должна иметь возможность получить доступ к записи, связанной с этим рейсом, без необходимости сначала читать записи для нескольких тысяч других рейсов.
Есть два метода, которые можно использовать, чтобы определить, где начинается чтение. В первом методе позиция файла, с которой начинается чтение, устанавливается для каждой операции чтения. Второй способ предусматривает специальную операцию по поиску нужного местоположения, поиск, задание текущего местоположения. После этой операции файл может быть прочитан последовательно с только что установленной позиции. Последний метод используется в UNIX и Windows.

Атрибуты файлов

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