Network OS
.pdfдрайверов, поддержка нескольких файловых систем, динамическая загрузка выгрузка драйверов и других.
Обобщенная структура подсистемы ввода вывода представлена на рис. 7.2.
Рис.7.2. Структура подсистемы ввода вывода Из рисунка видно, что программное обеспечение ввода вывода делится не только на
горизонтальные слои, но и на вертикальные. Это объясняется тем, что для такого разнообразного мира, как внешние устройства, трудно обеспечить единообразие в разбиении функций управления на слои. Поэтому общий принцип многослойности остается справедливым, однако для устройств определенного типа он реализуется по разному, со своим количеством слоев и их функциями. В представленной структуре в качестве примера приведены три вертикальные подсистемы, управляющие дисками, графическими устройствами, такими как мониторы, принтеры и плоттеры, и сетевыми адаптерами. Естественно, к этому перечню можно добавить и другие, например подсистему управления символьными терминалами или какими либо специализированными устройствами, такими как аналого цифровые и цифро аналоговые преобразователи.
Вкаждой вертикальной подсистеме существует несколько слоев модулей. Нижний слой образуют так называемые аппаратные драйверы устройств, название которых отражает тот факт, что они управляют аппаратурой внешних устройств, осуществляя обмен байтами и блоками байтов, и не имеют, как правило, дела с более высокоуровневыми вопросами логической организации данных, например с файлами или сложными графическими объектами. Функции вышележащих слоев в значительной степени зависят от типа вертикальной подсистемы.
Менеджер ввода вывода
Вподсистеме ввода вывода наряду с модулями, отражающими специфику внешних устройств и образующими вертикальные подсистемы, существуют модули универсального назначения. Эти модули организуют согласованную работу всех остальных компонентов подсистемы ввода вывода и взаимодействие с пользовательскими процессами и другими подсистемами ОС. Так же как и функции управления устройствами, эти организующие функции распределены по всем уровням, образуя оболочку. Эта оболочка иногда называется менеджером ввода вывода. Задачи такого менеджера довольно разнообразны.
Верхний слой менеджера составляют системные вызовы ввода вывода, которые принимают от пользовательских процессов запросы на ввод вывод и переадресуют их отвечающим за определенный класс устройств модулям и драйверам, а также возвращают процессам результаты операций ввода вывода. Таким образом этот слой поддерживает пользовательский интерфейс ввода вывода, создавая для прикладных программистов максимум удобств по манипулированию внешними устройствами и расположенными на них данными.
Нижний слой менеджера реализует непосредственное взаимодействие с контроллерами внешних устройств, экранируя драйверы от особенностей аппаратной платформы компьютера — шины ввода вывода, системы прерываний и т. п. Этот слой принимает от драйверов запросы на обмен данными с регистрами контроллеров в некоторой обобщенной форме с использованием независимых от шины ввода вывода адресации и формата, а затем преобразует эти запросы в зависящий от аппаратной платформы формат. Диспетчер прерываний, рассмотренный выше, может входить в состав менеджера ввода вывода или же представлять собой отдельный модуль ядра. В последнем случае менеджер ввода вывода выполняет для диспетчера прерываний первичную обработку запросов прерываний, передавая диспетчеру обобщенные сведения об источнике запроса.
Важной функцией менеджера ввода вывода является создание некоторой среды для
остальных компонентов подсистемы, которая бы облегчала их взаимодействие друг с другом. Эта задача может быть решена за счет создания некоторого стандартного внутреннего интерфейса взаимодействия модулей ввода вывода между собой, который бы дополнял внешние интерфейсы подсистемы с прикладными процессами, другими модулями ядра и аппаратурой. Наличие такого интерфейса существенно облегчает включение новых драйверов и файловых систем в состав ОС. Кроме того, разработчики драйверов и других программных компонентов освобождаются от написания общих процедур, таких как буферизация данных и синхронизация нескольких модулей между собой при обмене данными. Все эти функции берет на себя менеджер ввода вывода.
Еще одной функцией менеджера ввода вывода является организация взаимодействия модулей ввода вывода с модулями других подсистем ОС, таких как подсистема управления процессами, виртуальной памятью и другими.
Примерами подобного менеджера являются менеджер ввода вывода ОС Windows NT, а также среда STREAMS, существующая во многих версиях операционной системы UNIX. Менеджер ввода вывода Windows NT организует взаимодействие между модулями с помощью пакетов запросов ввода вывода — IRP (I/O Request Packet). Получив запрос от процедуры системного вызова, менеджер формирует IRP и передает его нужному драйверу. Драйвер после выполнения запрошенной операции возвращает ответ в виде другого IRP менеджеру, а тот, в свою очередь, может при необходимости передать этот IRP другому драйверу. Менеджер позволяет драйверам задавать взаимосвязи (bindings) между собой, и на основании информации о взаимосвязях и происходит передача пакетов IRP. Кроме того, менеджер Windows NT поддерживает динамическую загрузку выгрузку драйверов без останова системы.
Наличие стандартного внутреннего межмодульного интерфейса повышает устойчивость и улучшает расширяемость подсистемы ввода вывода, хотя может несколько замедлить ее работу, так как любое разделение на слои и части приводит к дополнительным операциям при взаимодействии по сравнению с монолитной организацией с прямыми передачами управления.
36. Многоуровневые драйверы. Блок ориентированные и байт ориентированные драйверы. Логическая организация файловой системы.
Многоуровневые драйверы
Первоначально термин «драйвер» применялся в достаточно узком смысле: под драйвером понимался программный модуль, который:
входит в состав ядра операционной системы, работая в привилегированном режиме; непосредственно управляет внешним устройством, взаимодействуя с его контроллером с
помощью команд ввода вывода компьютера; обрабатывает прерывания от контроллера устройства;
предоставляет прикладному программисту удобный логический интерфейс работы с устройством, экранируя от него низкоуровневые детали управления устройством и организации его данных;
взаимодействует с другими модулями ядра ОС с помощью строго оговоренного интерфейса, описывающего формат передаваемых данных, структуру буферов, способы включения драйвера в состав ОС, способы вызова драйвера, набор общих процедур подсистемы ввода вывода, которыми драйвер может пользоваться, и т. п.
Согласно этому определению драйвер вместе с контроллером устройства и прикладной программой воплощали идею многослойного подхода к организации программного обеспечения. Контроллер представлял нижний слой управления устройством, выполняющий операции в терминах блоков и агрегатов устройства (например, передвижение головки дисковода, побитную передачу байта по двухпроводному кабелю). Драйвер выполнял более сложные операции, преобразуя, например, данные, адресуемые в терминах номеров цилиндров, головок и секторов диска, в линейную последовательность блоков или устанавливая логическое соединение между двумя модемами через телефонную сеть. В результате прикладная программа уже работала с данными, преобразованными в достаточно понятную для человека форму, — файлами, таблицами баз данных, текстовыми окнами на мониторе и т. п., не вдаваясь в детали представления этих данных в устройствах ввода вывода. Кроме того, помещение драйвера в привилегированный режим и запрет для пользовательских процессов выполнять операции ввода вывода защищают критически важные для работы самой ОС устройства ввода вывода от ошибок прикладных программ, а также позволяют ОС надежно контролировать процесс разделения устройств и их данных между пользователями и процессами.
В описанной схеме драйверы не делились на слои. При этом они выполняли задачи разного уровня сложности: как самые примитивные, например просто последовательно передавали контроллеру байты для дальнейшего использования, так и достаточно сложные, связанные с отработкой протокола взаимодействия между модемами или вычерчиванием на экране математических кривых.
Постепенно, по мере развития операционных систем и усложнения структуры подсистемы ввода вывода, наряду с традиционными драйверами в операционных системах появились так называемые высокоуровневые драйверы, которые располагаются в общей модели подсистемы ввода вывода над традиционными драйверами. Появление высокоуровневых драйверов можно считать дальнейшим развитием идеи многослойной организации подсистемы ввода вывода. Вместо того чтобы концентрировать все функции по управлению устройством в одном программном модуле, во многих случаях гораздо эффективней распределить их между несколькими модулями в соседних слоях иерархии. Традиционные драйверы, которые стали называть аппаратными драйверами, низкоуровневыми драйверами, или драйверами устройств, подчеркивая их непосредственную связь с управляемым устройством, освобождаются от высокоуровневых функций и занимаются только низкоуровневыми операциями. Эти низкоуровневые операции составляют фундамент, на котором можно построить тот или иной набор операций в драйверах более высоких уровней. При таком подходе повышается гибкость и расширяемость функций по управлению устройством — вместо жесткого набора функций, сосредоточенных в единственном драйвере, администратор ОС может выбрать требуемый набор функций, установив нужный высокоуровневый драйвер. Если различным приложениям необходимо работать с различными логическими моделями одного и того же физического устройства, то для этого достаточно установить в системе несколько драйверов на одном уровне, работающих над одним аппаратным драйвером.
Количество уровней драйверов в подсистеме ввода вывода обычно не ограничивается каким либо пределом, но на практике чаще всего используют от двух до пяти уровней драйверов — слишком большое количество уровней может снизить скорость операций ввода вывода.
Несколько драйверов, управляющих одним устройством, но на разных уровнях, можно рассматривать как набор отдельных драйверов или как один многоуровневый драйвер. Высокоуровневые драйверы оформляются по тем же правилам и придерживаются тех же внутренних интерфейсов, что и аппаратные драйверы. Единственным отличием является то, что высокоуровневые драйверы, как правило, не вызываются по прерываниям, так как
взаимодействуют с управляемым устройством через посредничество аппаратных драйверов. Менеджер ввода вывода управляет драйверами однотипно, независимо от того, к какому уровню он относится. При наличии большого количества драйверов разного уровня усложняются связи между ними, что, в свою очередь, усложняет их взаимодействие, и именно эта ситуация привела к стандартизации внутреннего интерфейса в подсистеме ввода вывода и выделения специальной оболочки в виде менеджера ввода вывода, выполняющего служебные функции по организации работы драйверов.
Рассмотрим, как общие принципы построения многоуровневых драйверов могут быть реализованы при управлении определенными типами внешних устройств.
Ввертикальной подсистеме сетевых устройств, приведенной на рис. 7.2, аппаратными драйверами являются драйверы сетевых адаптеров, которые выполняют функции низкоуровневых канальных протоколов, таких как Ethernet, Frame Relay, ATM и других. Эти драйверы выполняют простые функции — они организуют передачу кадров данных между компьютерами одной сети. Над ними располагается слой модулей, которые реализуют функции более интеллектуальных протоколов сетевого уровня — IP и IPX, которые могут обеспечить взаимодействие компьютеров разных сетей с произвольной топологией связей. Модули IP и IPX также могут быть оформлены как драйверы, хотя они находятся в промежуточном программном слое и непосредственно с аппаратурой не взаимодействуют. Вообще, вертикальная подсистема управления сетевыми устройствами является примером эффективного многоуровнего подхода к организации драйверов — просто в силу того, что в ее основе лежит хорошо продуманная семиуровневая модель взаимодействия открытых систем OSI. И, хотя все семь уровней модели OSI обычно не выделяются в самостоятельные программные уровни, четыре уровня драйверов чаще всего присутствуют в подсистеме управления сетевыми устройствами. Над слоем драйверов сетевых протоколов располагается слой драйверов транспортных протоколов, таких как TCP/UDP, SPX и NetBEUI, которые отвечают за надежную связь между компьютерами сети. Еще выше расположен слой драйверов протоколов прикладного уровня (на рисунке — http, ftp и 8MB), которые предоставляют пользователям сети конечные услуги по доступу к гипертекстовой информации, архивам файлов и многие другие.
Вподсистеме управления графическими устройствами, такими как графические мониторы и принтеры, также существует несколько уровней драйверов. На нижнем уровне работают аппаратные драйверы, которые позволяют управлять конкретным графическим адаптером или принтером определенного типа, заставляя их выполнять некоторый набор примитивных графических операций: вывод точки, окружности, заполнение области цветом, вывод символов и т. п. Высокоуровневые графические драйверы строят на базе этих операций более мощные операции, например масштабирование изображения, преобразование графического формата в соответствии с разрешающими возможностями устройства и т. п. Самый верхний уровень подсистемы составляет менеджер окон, который создает для каждого приложения виртуальный образ экрана в виде набора окон, в которые приложение может выводить свои графические данные. Менеджер управляет окнами, отображая их в определенную область физического экрана или делая их невидимыми, а также предоставляет к ним совместный доступ с контролем прав доступа. Менеджер окон уже не зависит от особенностей конкретного графического устройства, предоставляя высокоуровневым драйверам заниматься преобразованием форматов выводимых данных.
Вподсистеме управления дисками аппаратные драйверы поддерживают для верхних уровней представление диска как последовательного набора блоков одинакового размера, преобразуя вместе с контроллером номер блока в более сложный адрес, состоящий из номеров цилиндра, головки и сектора. Однако такие понятия, как «файл» и «файловая система», аппаратные драйверы дисков не поддерживают — эти удобные для пользователя и программиста
логические абстракции создаются на более высоком уровне программным обеспечением файловых систем, которое в современных ОС также оформляется как драйвер, только высокоуровневый. Наличие универсальной среды, создаваемой менеджером ввода вывода, позволяет достаточно просто решить проблему поддержки в ОС нескольких файловых систем одновременно. Для этого в ОС устанавливается несколько высокоуровневых драйверов (на рисунке это драйверы файловых систем ufs, NTFS и FAT), работающих с общими аппаратными драйверами, но по своему организующими хранение данных в блоках диска и по своему представляющими файловую систему пользователю и прикладным процессам. Для унификации представления различных файловых систем в подсистеме ввода вывода может использоваться общий драйвер верхнего уровня, играющий роль диспетчера нескольких драйверов файловых систем. На рисунке в качестве примера показан диспетчер VFS (Virtual File System), применяемый в операционных системах UNIX, реализованных на основе кода System V Release 4.
Необязательно все модули подсистемы ввода вывода оформляются в виде драйверов. Например, в подсистеме управлениями дисками обычно имеется такой модуль, как дисковый кэш, который служит для кэширования блоков дисковых файлов в оперативной памяти. Достаточно специфические функции кэша делают нецелесообразным оформление его в виде драйвера, взаимодействующего с другими модулями ОС только с помощью услуг менеджера ввода вывода. Другим примером модуля, который чаще всего не оформляется в виде драйвера, является диспетчер окон графического интерфейса. Иногда этот модуль вообще выносится из ядра ОС и реализуется в виде пользовательского процесса. Таким образом был реализован диспетчер окон (а также высокоуровневые графические драйверы) в Windows NT 3.5 и 3.51, но этот микроядерный подход заметно замедлял графические операции, поэтому в Windows NT 4.0 диспетчер окон и высокоуровневые графические драйверы, а также графическая библиотека GDI были перенесены в пространство ядра.
Аппаратные драйверы после запуска операции ввода вывода должны своевременно реагировать на завершение контроллером заданного действия, и для решения этой задачи они взаимодействуют с системой прерываний. Драйверы более высоких уровней вызываются уже не по прерываниям, а по инициативе аппаратных драйверов или драйверов вышележащего уровня. Не все процедуры аппаратного драйвера нужно вызывать по прерываниям, поэтому драйвер обычно имеет определенную структуру, в которой выделяется секция обработки прерываний (Interrupt Service Routine, ISR), которая и вызывается при поступлении запроса от соответствующего устройства диспетчером прерываний. Диспетчер прерываний можно считать частью подсистемы ввода вывода, как это показано на рис. 7.2, а можно считать и независимым модулем ядра ОС, так как он служит не только для вызова секций обработки прерываний драйверов, но и для диспетчеризации прерываний других типов.
В унификацию драйверов большой вклад внесла операционная система UNIX. В ней все драйверы были разделены на два больших класса: блок ориентированные (block oriented) драйверы и байт ориентированные (character oriented) драйверы. Это деление является более общим, чем показанное на рис. 7.2 деление на вертикальные подсистемы. Например, драйверы графических устройств и драйверы сетевых устройств относятся к классу байт ориентированных.
Блок ориентированные драйверы управляют устройствами прямого доступа, которые хранят информацию в блоках фиксированного размера, каждый из которых имеет собственный адрес. Самое распространенное внешнее устройство прямого доступа — диск. Адресуемость блоков приводит к тому, что для устройств прямого доступа появляется возможность кэширования данных в оперативной памяти, и это обстоятельство значительно влияет на общую организацию ввода вывода для блок ориентированных драйверов.
Устройства, с которыми работают байт ориентированные драйверы, не адресуемы и не
позволяют производить операцию поиска данных, они генерируют или потребляют последовательности байт. Примерами таких устройств, которые также называют устройствами последовательного доступа, служат терминалы, строчные принтеры, сетевые адаптеры.
Значительность отличий блок ориентированных и байт ориентированных драйверов иллюстрирует тот факт, что среда STREAMS разработана только для байт ориентированных драйверов и включить в нее блок ориентированный драйвер невозможно.
Блок или байт ориентированность является характеристикой как самого устройства, так и драйвера. Очевидно, что если устройство не поддерживает обмен адресуемыми блоками данных, а позволяет записывать или считывать последовательность байт, то и устройство, и его драйвер можно назвать байт ориентированными. Для байт ориентированного устройства невозможно разработать блок ориентированный драйвер. Устройство прямого доступа с блочной адресацией является блок ориентированным, и для управления им естественно использовать блок ориентированный драйвер. Однако блок ориентированным устройством можно управлять и с помощью байт ориентированного драйвера. Так, диск можно рассматривать не только как набор блоков, но и как набор байт, первый из которых начинает первый блок диска, а последний завершает последний блок. Физический обмен с контроллером устройства по прежнему осуществляется блоками, но байт ориентированный драйвер устройства будет преобразовывать блоки в последовательность байт. Для устройств прямого доступа часто разрабатывают пару драйверов, чтобы к устройству можно было обращаться и по байт ориентированному, и по блок ориентированному интерфейсам в зависимости от потребностей.
Деление всех драйверов на блок ориентированные и байт ориентированные оказывается полезным для структурирования подсистемы управления вводом выводом. Тем не менее необходимо учитывать, что эта схема является упрощенной — имеются внешние устройства, драйверы которых не относятся ни к одному классу, например таймер, который, с одной стороны, не содержит адресуемой информации, а с другой стороны, не порождает потока байт. Это устройство только выдает сигнал прерывания в некоторые моменты времени. Операционная система UNIX в свое время сделала еще один важный шаг по унификации операций и структуризации программного обеспечения ввода вывода. В ОС UNIX все устройства рассматриваются как некоторые виртуальные (специальные) файлы, что дает возможность использовать общий набор базовых операций ввода вывода для любых устройств независимо от их специфики. Эти вопросы обсуждаются в следующем разделе, посвященном файлам и файловым системам.
Специальные файлы
Специальные файлы, называемые иногда виртуальными, не связаны со статичными наборами данных, хранящихся на дисках, а являются удобным унифицированным представлением устройств ввода вывода.
Понятие специального файла появилось в операционной системе UNIX. Специальный файл всегда связан с некоторым устройством ввода вывода и представляет его для остальной части операционной системы и прикладных процессов в виде неструктурированного набора байт. Со специальным файлом можно работать так же, как и с обычным, то есть открывать, считывать из него определенное количество байт или же записывать в него определенное количество байт, а после завершения операции закрывать. Для этого используются те же системные вызовы, что и для работы с обычными файлами: open, create, read, write и close. Таким образом, для того чтобы вывести на алфавитно цифровой терминал, с которым связан специальный файл /dev/tty3, сообщение "Hello, friends!", достаточно открыть этот файл с помощью системного вызова open:
fd =open ("/de/tty3". 2)
Затем можно вывести сообщение с помощью системного вызова write: write (fd, "Hello, friends!". 15)
Для устройств прямого доступа имеет смысл также указатель текущего положения в файле, которым можно управлять с помощью системного вызова lseek.
Очевидно, что представление устройства в виде файла и использование для управления устройством файловых системных вызовов во многих случаях не позволяет выполнять только достаточно простые операции.
Традиционно специальные файлы помещаются в каталог /dev, хотя ничто не мешает создать их в любом каталоге файловой системы. При появлении нового устройства и соответственно нового драйвера администратор системы может создать новую запись с помощью
команды mknod. Например, следующая команда создает блок ориентированный специальный файл:
mknod /dev/dsk/sc4d2s3 b 32 33
Логическая организация файловой системы Одной из основных задач операционной системы является предоставление удобств
пользователю при работе с данными, хранящимися на дисках. Для этого ОС подменяет физическую структуру хранящихся данных некоторой удобной для пользователя логической моделью. Логическая модель файловой системы материализуется в виде дерева каталогов, выводимого на экран такими утилитами, как Norton Commander или Windows Explorer, в символьных составных именах файлов, в командах работы с файлами. Базовым элементом этой модели является файл, который так же, как и файловая система в целом, может характеризоваться как логической, так и физической структурой.
37. Цели и задачи файловой системы. Типы файлов.
Цели и задачи файловой системы
Файл — это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Файлы хранятся в памяти, на зависящей от энергопитания, обычно — на магнитных дисках. Однако нет правил без исключения. Одним из таких исключений является так называемый электронный диск, когда в оперативной памяти создается структура, имитирующая файловую систему.
Основные цели использования файла перечислены ниже.
Долговременное и надежное хранение информации. Долговременность достигается за счет использования запоминающих устройств, не зависящих от питания, а высокая надежность определяется средствами защиты доступа к файлам и общей организацией программного кода ОС, при которой сбои аппаратуры чаще всего не разрушают информацию, хранящуюся в файлах.
Совместное использование информации. Файлы обеспечивают естественный и легкий способ разделения информации между приложениями и пользователями за счет наличия понятного человеку символьного имени и постоянства хранимой информации и расположения файла. Пользователь должен иметь удобные средства работы с файлами, включая каталоги справочники, объединяющие файлы в группы, средства поиска файлов по признакам, набор команд для создания, модификации и удаления файлов. Файл может быть создан одним пользователем, а затем использоваться совсем другим пользователем, при этом создатель файла или администратор могут определить права доступа к нему других пользователей. Эти цели реализуются в ОС файловой системой.
Файловая система (ФС) — это часть операционной системы, включающая:
совокупность всех файлов на диске; наборы структур данных, используемых для управления файлами, такие, например, как
каталоги файлов, дескрипторы файлов, таблицы распределения свободного и занятого пространства на диске;
комплекс системных программных средств, реализующих различные операции над файлами, такие как создание, уничтожение, чтение, запись, именование и поиск файлов.
Файловая система позволяет программам обходиться набором достаточно простых операций для выполнения действий над некоторым абстрактным объектом, представляющим файл. При этом программистам не нужно иметь дело с деталями действительного расположения данных на диске, буферизацией данных и другими низкоуровневыми проблемами передачи данных с долговременного запоминающего устройства. Все эти функции файловая система берет на себя. Файловая система распределяет дисковую память, поддерживает именование файлов, отображает имена файлов в соответствующие адреса во внешней памяти, обеспечивает доступ к данным, поддерживает разделение, защиту и восстановление файлов. Таким образом, файловая система играет роль промежуточного слоя, экранирующего все сложности физической организации долговременного хранилища данных, и создающего для программ более простую логическую модель этого хранилища, а также предоставляя им набор удобных в использовании команд для манипулирования файлами.
Задачи, решаемые ФС, зависят от способа организации вычислительного процесса в целом. Самый простой тип — это ФС в однопользовательских и однопрограммных ОС, к числу которых относится, например, MS DOS. Основные функции в такой ФС нацелены на решение следующих задач:
именование файлов; программный интерфейс для приложений;
отображения логической модели файловой системы на физическую организацию хранилища данных;
устойчивость файловой системы к сбоям питания, ошибкам аппаратных и программных средств.
Задачи ФС усложняются в операционных однопользовательских мультипрограммных ОС, которые, хотя и предназначены для работы одного пользователя, но дают ему возможность запускать одновременно несколько процессов. Одной из первых ОС этого типа стала OS/2. К перечисленным выше задачам добавляется новая задача совместного доступа к файлу из нескольких процессов. Файл в этом случае является разделяемым ресурсом, а значит, файловая система должна решать весь комплекс проблем, связанных с такими ресурсами. В частности, в ФС должны быть предусмотрены средства блокировки файла и его частей, предотвращения гонок, исключение тупиков, согласование копий и т. п.
В многопользовательских системах появляется еще одна задача: защита файлов одного пользователя от несанкционированного доступа другого пользователя.
Еще более сложными становятся функции ФС, которая работает в составе сетевой ОС. Эта тема рассматривается в последней главе книги, посвященной управлению сетевыми ресурсами.
Типы файлов
Файловые системы поддерживают несколько функционально различных типов файлов, в число которых, как правило, входят обычные файлы, файлы каталоги, специальные файлы, именованные конвейеры, отображаемые в память файлы и другие.
Обычные файлы, или просто файлы, содержат информацию произвольного характера, которую заносит в них пользователь или которая образуется в результате работы системных и пользовательских программ. Большинство современных операционных систем (например, UNIX, Windows, OS/2) никак не ограничивает и не контролирует содержимое и структуру обычного файла. Содержание обычного файла определяется приложением, которое с ним работает. Например, текстовый редактор создает текстовые файлы, состоящие из строк символов, представленных в каком либо коде. Это могут быть документы, исходные тексты программ и т. п. Текстовые файлы можно прочитать на экране и распечатать на принтере. Двоичные файлы не используют коды символов, они часто имеют сложную внутреннюю структуру, например исполняемый код программы или архивный файл. Все операционные системы должны уметь распознавать хотя бы один тип файлов — их собственные исполняемые файлы.
Каталоги — это особый тип файлов, которые содержат системную справочную информацию о наборе файлов, сгруппированных пользователями по какому либо неформальному признаку (например, в одну группу объединяются файлы, содержащие документы одного договора, или файлы, составляющие один программный пакет). Во многих операционных системах в каталог могут входить файлы любых типов, в том числе другие каталоги, за счет чего образуется древовидная структура, удобная для поиска. Каталоги устанавливают соответствие между именами файлов и их характеристиками, используемыми файловой системой для управления файлами. В число таких характеристик входит, в частности, информация (или указатель на другую структуру, содержащую эти данные) о типе файла и расположении его на диске, правах доступа к файлу и датах его создания и модификации. Во всех остальных отношениях каталоги рассматриваются файловой системой как обычные файлы.
Специальные файлы — это фиктивные файлы, ассоциированные с устройствами ввода вывода, которые используются для унификации механизма доступа к файлам и внешним устройствам. Специальные файлы позволяют пользователю выполнять операции ввода вывода посредством обычных команд записи в файл или чтения из файла. Эти команды обрабатываются сначала программами файловой системы, а затем на некотором этапе выполнения запроса преобразуются операционной системой в команды управления соответствующим устройством.
Современные файловые системы поддерживают и другие типы файлов, такие как символьные связи, именованные конвейеры, отображаемые в память файлы. Они будут рассмотрены позже.
38. Иерархическая структура файловой системы. Имена файлов, монтирование, атрибуты файлов.
Иерархическая структура файловой системы
Пользователи обращаются к файлам по символьным именам. Однако способности человеческой памяти ограничивают количество имен объектов, к которым пользователь может обращаться по имени. Иерархическая организация пространства имен позволяет значительно расширить эти границы. Именно поэтому большинство файловых систем имеет иерархическую структуру, в которой уровни создаются за счет того, что каталог более низкого уровня может входить в каталог более высокого уровня (рис. 7.3).
Рис. 7.3. Иерархия файловых систем Граф, описывающий иерархию каталогов, может быть деревом или сетью. Каталоги образуют
дерево, если файлу разрешено входить только в один каталог (рис. 7.3, б), и сеть — если файл может входить сразу в несколько каталогов (рис. 7.3, в). Например, в MS DOS и Windows каталоги образуют древовидную структуру, а в UNIX — сетевую. В древовидной структуре каждый файл является листом. Каталог самого верхнего уровня называется корневым каталогом, или корнем (root).
При такой организации пользователь освобожден от запоминания имен всех файлов, ему достаточно примерно представлять, к какой группе может быть отнесен тот или иной файл, чтобы путем последовательного просмотра каталогов найти его. Иерархическая структура удобна для многопользовательской работы: каждый пользователь со своими файлами локализуется в своем каталоге или поддереве каталогов, и вместе с тем все файлы в системе логически связаны.
Частным случаем иерархической структуры является одноуровневая организация, когда все файлы входят в один каталог (рис. 7.3, а).
Имена файлов
Все типы файлов имеют символьные имена. В иерархически организованных файловых системах обычно используются три типа имен файлов: простые, составные и относительные. Простое, или короткое, символьное имя идентифицирует файл в пределах одного каталога. Простые имена присваивают файлам пользователи и программисты, при этом они должны учитывать ограничения ОС как на номенклатуру символов, так и на длину имени. До сравнительно недавнего времени эти границы были весьма узкими. Так, в популярной файловой системе FAT длина имен ограничивались схемой 8.3 (8 символов — собственно имя, 3 символа — расширение имени), а в файловой системе s5, поддерживаемой многими версиями ОС UNIX, простое символьное имя не могло содержать более 14 символов. Однако пользователю гораздо удобнее работать с длинными именами, поскольку они позволяют дать файлам легко запоминающиеся названия, ясно говорящие о том, что содержится в этом файле. Поэтому современные файловые системы, а также усовершенствованные варианты уже существовавших файловых систем, как правило, поддерживают длинные простые символьные имена файлов. Например, в файловых сие • темах NTFS и FAT32, входящих в состав операционной системы Windows NT, имя файла может содержать до 255 символов. Примеры простых имен файлов и каталогов:
quest_ul.doc task entran.exe
приложение к СО 254L на русском языке.doc installable filesystem manager.doc
Виерархических файловых системах разным файлам разрешено иметь одинаковые простые символьные имена при условии, что они принадлежат разным каталогам. То есть здесь работает схема «много файлов — одно простое имя». Для одпозначной идентификации файла в таких системах используется так называемое полное имя.
Полное имя представляет собой цепочку простых символьных имен всех каталогов, через которые проходит путь от корня до данного файла. Таким образом, полное имя является составным, в котором простые имена отделены друг от друга принятым в ОС разделителем. Часто в качестве разделителя используется прямой или обратный слеш, при этом принято не указывать имя корневого каталога. На рис. 7.3, б два файла имеют простое имя main.exe, однако их составные имена /depart/main.ехе и /user/anna/main.exe различаются.
Вдревовидной файловой системе между файлом и его полным именем имеется взаимно однозначное соответствие «один файл — одно полное имя». В файловых системах, имеющих сетевую структуру, файл может входить в несколько каталогов, а значит, иметь несколько полных имен; здесь справедливо соответствие «один файл — много полных имен». В обоих случаях файл однозначно идентифицируется полным именем.