Потоки данных в UNIX

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

Первое решение, реализованное в системе BSD, основано на структурах данных, при­сутствующих в классических системах UNIX и называемых С-списками. Каждый С-список представляет собой блок размером до 64 символов плюс счетчик и указатель на следующий блок. Символы, поступающие с терминала или любого другого символьного устройства, буферизируются в цепочках таких блоков. Когда пользовательский процесс считывает данные из /dev/tty (то есть из стандартного входного потока), символы не передаются процессу напрямую из С-списков. Вместо этого они пропускаются через процедуру, расположенную в ядре и называемую дисциплиной линии связи. Дисциплина линии связи ра­ботает как фильтр, принимая необработанный поток символов от драйвера терми­нала, обрабатывая его и формируя то, что называется обработанным символьным потоком. В обработанном потоке выполняются операции локального строково­го редактирования (например, удаляются отмененные пользователем символы и строки), а также выполняются другие специальные операции обработки. Обработанный поток передается процессу. Однако если процесс желает воспринимать каждый символ, введенный пользователем, он может принимать необработанный поток, минуя дисциплину линии связи. Вывод работает аналогично, заменяя табуляторы пробелами, добавляя символы-заполнители и т. д. Как и входной поток, выходной символьный поток может быть пропущен через дисциплину линии связи (обработанный режим) или мино­вать ее (необработанный режим). Необработанный режим особенно полезен при отправке двоичных данных на другие машины по линии последовательной передачи или для графических интерфейсов пользователя. Здесь не требуется ни­какого преобразования.

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

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

Важное свойство потоков данных – мультиплексирование. Мультиплексный модуль может взять один по­ток и расщепить его на несколько потоков или, наоборот, объединить несколько потоков в единый поток.

7.5. Файловые системы UNIX

Основные понятия

Файл в системе UNIX – это последовательность байтов произвольной длины (от 0 до некоторого максимума), содержащая произвольную информацию. Не делается принципиального различия между текстовыми (ASCII) файлами, двоичными фай­лами и любыми другими файлами. Значение битов в файле целиком определяется владельцем файла. Системе это безразлично. Изначально размер имен файлов был ограничен 14 символами, но в системе Berkeley UNIX этот предел был расширен до 255 символов, что впоследствии было принято в System V, а также в большин­стве других версий. В именах файлов разрешается использовать все ASCII-симво­лы, кроме символа NUL.

По соглашению многие программы ожидают, что имена файлов должны состоять из основного имени и расширения, отделяемого от основного имени файла точкой (которая в системе UNIX также считается символом). Эти со­глашения никак не регулируются операционной системой, но некоторые компи­ляторы и другие программы ожидают файлов именно с такими расширениями. Расширения могут иметь произвольную длину, кроме того, файлы могут иметь по нескольку расширений.

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

Существует два способа задания имени файла в системе UNIX, как в оболочке, так и при открытии файла из программы. Первый способ заключается в использо­вании абсолютного пути, указывающего, как найти файл от корневого каталога. Пример абсолютного пути: /man/labs/operat/numb4. Он сообщает системе, что в корневом каталоге следует найти каталог man, затем в нем найти каталог labs, ко­торый содержит каталог operat, а в нем расположен файл numb4.

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

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

Кроме обычных файлов, системой UNIX также поддерживаются символьные специальные файлы и блочные специальные файлы. Символьные специальные файлы используются для моделирования последовательных устройств ввода-вы­вода, таких как клавиатуры и принтеры. Если процесс откроет файл /dev/tty и про­читает из него, он получит символы, введенные с клавиатуры. Если открыть файл /dev/lp и записать в него данные, то эти данные будут распечатаны на принтере.

Блочные специальные файлы, часто с такими именами, как /dev/hd1, могут исполь­зоваться для чтения и записи необработанных дисковых разделов, минуя файло­вую систему. Таким образом, поиск байта номер k, за которым последует чтение, приведет к чтению k-то байта на соответствующем дисковом разделе, игнорируя i-узел и файловую структуру. Необработанные блочные устройства используют­ся для страничной подкачки и свопинга программами установки файловой систе­мы (например, mkfs) и программами, исправляющими ломаные файловые систе­мы (например, fsck).

При наличии у вычислительной машины нескольких дисков возникает вопрос управления ими. Одно из решений заключается в том, чтобы установить самостоятельную файло­вую систему на каждый отдельный диск и управлять ими как отдельными файло­выми системами. При таком решении пользователь должен помимо каталогов указывать также и устройство, если оно отличается от используемого по умолчанию. Такой подход применяется в операционных системах MS-DOS, Windows 98 и VMS. Решение, применяемое в операционной системе UNIX, заключается в том, чтобы позволить монтировать один диск в дерево файлов другого диска. Например, можно смонтировать дискету в каталог жесткого диска. При этом пользователь будет видеть еди­ное дерево файлов и уже не должен думать о том, какой файл на каком устройстве хранится.

Другим интересным свойством файловой системы UNIX является бло­кировка. В некоторых приложениях два и более процессов могут одновременно использовать один и тот же файл, что может привести к конфликту. Одно из ре­шений данной проблемы заключается в том, чтобы создать в приложении крити­ческие области. Однако если эти процессы принадлежат независимым пользова­телям, такой способ координации действий, как правило, очень неудобен. Рассмотрим, например, базу данных, состоящую из многих файлов в одном или нескольких каталогах, доступ к которым могут получить никак не связанные меж­ду собой пользователи. С каждым каталогом или файлом можно связать семафор и достичь взаимного исключения, заставляя процессы выполнять операцию down на соответствующем семафоре, прежде чем читать или писать определенные дан­ные. Недостаток этого решения заключается в том, что недоступным становится весь каталог или файл, даже если процессам нужна всего одна запись. По этой причине стандартом POSIX предоставляется гибкий и детальный ме­ханизм, позволяющий процессам за одну неделимую операцию блокировать даже единственный байт файла или целый файл по желанию. Механизм блокировки требует от вызывающего его процесса указать блокируемый файл, начальный байт и количество байтов. Если операция завершается успешно, система создает запись в таблице, в которой указывается, что определенные байты файла заблокированы.

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