Эта глава охватывает следующие темы:
Введение
Менеджер файловой системы (Fsys) обеспечивает стандартизованные способы сохранения данных на дисках и доступа к ним. Fsys отвечает за обработку всех запросов на открытие, закрытие, чтение и запись файлов.
Что такое файл?
В QNX файл - это объект, в который может производиться запись, из которого может производиться чтение, либо и то и другое. QNX поддерживает шесть типов файлов; пять из них поддерживает Fsys:
- регулярные файлы - состоят из последовательности байт с произвольным доступом и не имеют предопределенной структуры;
- каталоги - содержат информацию, необходимую для поиска регулярных файлов; также содержат статус и атрибуты для каждого регулярного файла;
- символические связи - содержат путь к файлу или каталогу, к которым перенаправляются все запросы; символические связи часто используются для предоставления множества путей к одному файлу;
- программные каналы (pipes) и FIFO - служат как каналы ввода/вывода между взаимодействующими процессами;
- блок-ориентированные файлы - относятся к устройствам, таким, как диски, ленты и разделы дисков. Доступ к этим файлам обычно осуществляется таким образом, что аппаратные характеристики устройств скрыты от приложений.
Все эти типы файлов подробно описываются в этой главе. Шестой тип файлов - блок-ориентированные файлы - обслуживается Менеджером устройств.
Метки даты и времени
Fsys поддерживает четыре различных метки времени для каждого файла. Это:
- дата последнего доступа (чтения);
- дата последней записи;
- дата последней модификации;
- дата создания (уникальна для QNX).
Доступ к файлам
Доступ к регулярным файлам и каталогам управляется битами режима, хранящимися в inode (индексном дескрипторе) файла. Более подробно inode описан в секции "Связи и индексные дескрипторы (inodes)". Эти биты разрешают чтение, запись и выполнение в зависимости от эффективных ID пользователя и группы. При этом пользователи делятся на три категории:
- владелец файла;
- члены группы, к которой принадлежит владелец;
- остальные.
Процесс может выполняться с ID пользователя или ID группы файла, а не родительского процесса. Механизм, который позволяет это, называется setuid (установить ID пользователя) и setgid (установить ID группы).
Регулярные файлы и каталоги
Регулярные файлы
QNX рассматривает регулярный файл как последовательность байт с возможностью произвольного доступа и не имеющую другой предопределенной внутренней структуры. Прикладные программы сами несут ответственность за понимание структуры и содержания конкретного регулярного файла.
Регулярные файлы составляют большинство файлов в файловых системах. Файловые системы поддерживаются Менеджером файловой системы и реализованы на базе блок-ориентированных файлов, соответствующих разделам диска (разделы описаны в секции "Работа с дисками").
Каталоги
Каталог - это файл, который содержит элементы каталога. Каждый элемент каталога увязывает имя файла с файлом. Имя файла - это символьное имя, которое позволяет идентифицировать файл и работать с ним. Файл может быть идентифицирован несколькими именами (смотри секции "Связи и индексные дескрипторы (inodes)" и "Символические связи").
Следующая диаграмма показывает, как производится поиск файла с именем /usr/bill/file2.
Путь в структуре каталога QNX к файлу /usr/bill/file2.
Операции с каталогами
Хотя каталог ведет себя во многом как стандартный файл, Менеджер файловой системы накладывает некоторые ограничения на операции, которые вы можете производить с каталогом. В частности, вы не можете открыть каталог для записи либо создать связь для каталога с помощью функции Си link().
Чтение элементов каталога
Для чтения элементов каталога вы можете использовать набор функций Си, определенных POSIX, которые обеспечивают не зависимый от ОС доступ к элементам каталога. Эти функции включают:
- opendir()
- readdir()
- rewinddir()
- closedir()
Так как каталоги QNX - это просто файлы, содержащие "известную" информацию, вы можете также читать элементы каталога непосредственно функциями Си open() и read(). Однако эта техника не переносима - формат элементов каталога отличается в различных операционных системах.
Экстенты
В QNX регулярные файлы и файлы каталога хранятся как последовательность экстентов. Экстент - это непрерывная последовательность блоков на диске.
Где хранятся экстенты
Файлы, которые состоят только из одного экстента, хранят информацию об экстенте в элементе каталога. Но, если файл состоит более чем из одного экстента, информация о расположении экстентов хранится в одном или более связных блоках экстентов (связные - имеющие прямые/обратные указатели). Каждый блок экстентов может содержать информацию не более чем о 60 экстентах.
Файл, состоящий из множества непрерывных областей на диске, называемых в QNX экстентами.
Увеличение файлов
Когда Менеджеру файловой системы необходимо увеличить файл, он сначала пытается увеличить последний экстент, хотя бы даже на один блок. Но если последний экстент не может быть дополнен, то для расширения файла выделяется новый экстент.
Для выделения новых экстентов Менеджер файловой системы использует метод "первого попадания". Специальная таблица в Менеджере файловой системы содержит сведения обо всех блоках, описанных в файле /.bitmap (этот файл описан в секции "Ключевые компоненты раздела QNX"). Для каждого блока указывается размер соответствующего ему свободного экстента. Менеджер файловой системы выбирает из таблицы первый достаточно большой экстент.
Связи и индексные дескрипторы (inodes)
В QNX файл может обозначаться более чем одним именем. Каждое имя файла называется связью. В действительности существует два вида связей: жесткие связи, или просто "связи", и символические связи. Символические связи описаны в следующей секции.
Для поддержки связей каждого файла, имя файла отделяется от остальной информации, описывающей файл. Эта информация хранится в структуре, называемой inode (индексным дескриптором).
Если файл имеет только одну связь (т.е. одно имя), то блок inode хранится в элементе каталога для этого файла. Но если файл имеет более чем одну связь, то inode хранится как запись в специальном файле /.inodes, а элемент каталога для файла содержит указатель на запись inode.
Учтите, что вы можете создать связь для файла, только если файл и связь находятся в одной и той же файловой системе.
Один и тот же файл обозначен двумя связями с именами "more" и "less".
Существует еще две ситуации, в которых для файла создается запись в файле /.inodes:
- если имя файла длиннее чем 16 символов, то информация inode хранится в файле /.inodes, оставляя место в элементе каталога для 48-символьного имени файла;
- если файл имел более одной связи и все связи, кроме одной, были удалены, то за файлом сохраняется отдельная запись в файле /.inodes. Это сделано, чтобы избежать поиска элемента каталога, указывающего на inode (элементы inode не имеют обратных связей с элементами каталога).
| Если вы хотите: | Используйте: |
| Создать связь из командного интерпретатора |
Утилиту ln |
| Создать связь из программы |
Функцию link() |
Удаление связей
При создании файла, для него устанавливается счетчик связей, равный единице. По мере добавления ссылок этот счетчик увеличивается; при удалении связи счетчик связей уменьшается. Файл не удаляется с диска до того, как счетчик связей станет равным нулю и все программы, использующие этот файл, закроют его. Это позволяет использовать открытый файл даже после того, как у него удалены все связи.
| Если вы хотите: | Используйте: |
| Удалить связь из командного интерпретатора |
Утилиту rm |
| Удалить связь из программы |
Функции remove() или unlink() |
Связи каталога
Вы не можете создавать жесткие связи для каталога. Однако каждый каталог имеет две жестко определенные связи:
- . ("точка")
- .. ("точка точка")
Имя файла "точка" соответствует текущему каталогу; "точка точка" соответствует каталогу, предшествующему текущему каталогу.
Заметьте, что "точка точка" для каталога "/" - это просто "/", - вы не можете подняться выше.
Символические связи
Символическая связь - это особый файл, который содержит в качестве данных имя пути. Когда символическая связь используется в запросе ввода/вывода - например, open(), - обозначение связи в имени пути заменяется ее "данными". Символическая связь является гибким средством для перенаправления пути и часто используется для создания множества путей к одному и тому же файлу. В отличие от жестких связей, символические связи могут выходить за пределы файловой системы и также являться связями для каталогов.
В следующем примере каталоги //1/usr/fred и //2/usr/barney являются связями на один и тот же каталог, хотя они находятся в различных файловых системах, и даже на различных узлах (смотри следующую диаграмму). Это не может быть сделано с использованием жестких связей:
//1/usr/fred --> //2/usr/barney
Заметьте, что символическая связь и адресуемый каталог не обязаны иметь одно и то же имя. В большинстве случаев символические связи используются для привязки одного каталога к другому. Однако они также могут быть использованы для файлов, как в этом примере:
//1/usr/eric/src/test.c --> //1/usr/src/game.c
| Если вы хотите: | Используйте утилиту: |
| Создать символическую связь |
ln (с опцией -s) |
| Удалить символическую связь* |
rm |
| Узнать, является ли файл символической связью |
ls |
* Помните, что удаление символической связи действует только на связь, а не на адресуемый объект
Некоторые функции оперируют непосредственно с символическими связями. Для этих функций замена обозначения связи в пути на ее содержимое не производится. К этим функциям относятся unlink() (которая удаляет символическую связь), lstat() и readlink().
Так как символические связи могут указывать на каталоги, то неверная конфигурация может привести к проблемам, таким, как циклические связи. Чтобы защититься от циклических связей, система накладывает ограничения на количество переходов; этот предел определен как SYMLOOP_MAX во включаемом файле .
Программные каналы (pipes) и FIFO
Программные каналы (pipes)
Программный канал - это неименованный файл, который служит как канал ввода/вывода между двумя или более взаимодействующими процессами - один процесс пишет в программный канал, другой читает из программного канала. Менеджер файловой системы обеспечивает буферизацию данных. Размер буфера определен как PIPE_BUF в файле . Программный канал удаляется после того как закрыты оба его конца.
Программные каналы обычно используются, когда два процесса хотят выполняться параллельно, с однонаправленной передачей данных от одного процесса к другому. Если требуется двунаправленная передача данных, то должны использоваться сообщения.
Типичное применение программного канала состоит в соединении вывода одной программы с вводом другой программы. Это соединение часто производится командным интерпретатором (Shell). Например:
ls | more
направляет стандартный вывод от утилиты ls через программный канал в стандартный ввод утилиты more.
| Если вы хотите: | Используйте: |
| Создать программный канал из командного интерпретатора |
Символ программного канала ("|") |
| Создать программный канал из программы |
Функции pipe() или popen() |
 |
На бездисковых рабочих станциях вы можете запустить Менеджер программных каналов (Pipe) вместо Менеджера файловой системы, когда требуются только программные каналы. Менеджер программных каналов оптимизирован для канального (конвейерного) ввода/вывода и может обеспечить большую пропускную способность, чем Менеджер файловой системы. |
FIFO
FIFO - это по существу то же самое, что и программные каналы, за исключением того, что FIFO являются именованными постоянными файлами, которые хранятся в каталогах файловой системы.
| Если вы хотите: | Используйте: |
| Создать FIFO из командного интерпретатора |
Утилиту mkfifo |
| Создать FIFO из программы |
Функцию mkfifo() |
| Удалить FIFO из командного интерпретатора |
Утилиту rm |
| Удалить FIFO из программы |
Функции remove() или unlink() |
Производительность Менеджера файловой системы
Свойства Менеджера файловой системы, обеспечивающие высокопроизводительный доступ к диску:
- лифтовый поиск;
- кэш-буфер;
- многопотоковая обработка;
- клиент-управляемый приоритет;
- временные файлы;
- псевдодиски.
Лифтовый поиск
Лифтовый поиск минимизирует общие затраты времени на позиционирование магнитной головки при чтении или записи на диск. Запросы ввода/вывода упорядочиваются таким образом, чтобы все они могли быть выполнены за один проход магнитной головки, от самого младшего к самому старшему адресу на диске.
Лифтовый поиск также имеет усовершенствование, обеспечивающее выполнение мультисекторного ввода/вывода там, где возможно.
Кэш-буфер
Кэш-буфер - это интеллектуальный буфер между Менеджером файловой системы и драйвером диска. Кэш-буфер хранит блоки файлов с целью минимизировать количество обращений Менеджера файловой системы к диску. По умолчанию размер кэша определяется общим объемом оперативной памяти, но вы можете задать другое значение через опцию при запуске Fsys.
Операции чтения являются синхронными. Операции записи, напротив, обычно являются асинхронными. Когда данные попадают в кэш, Менеджер файловой системы отвечает клиенту (функцией Reply()), извещая его, что данные записаны. Затем выполняется запись данных на диск с максимально-возможной скоростью, обычно не позднее, чем через пять секунд.
Приложения могут изменять механизм записи применительно к конкретным файлам. Например, приложение, работающее с базой данных, может потребовать, чтобы запись в определенный файл производилась синхронно. Это обеспечит высокий уровень целостности файла в случае аппаратного или программного сбоя.
Многопотоковая обработка
Менеджер файловой системы является многопотоковым процессом, и, таким образом, он может обрабатывать несколько запросов ввода/вывода одновременно. Это позволяет Менеджеру файловой системы в полной мере реализовать возможности параллельной обработки, так как он в состоянии:
- получить одновременный доступ к нескольким устройствам;
- удовлетворить запросы ввода/вывода из кэш-буфера, в то время как выполняются другие запросы ввода/вывода, осуществляющие доступ к диску.
Клиент-управляемый приоритет
Приоритет Менеджера файловой системы может определяться приоритетом процесса, пославшего ему запрос. В этом случае, когда Менеджер файловой системы получает сообщение, его приоритет устанавливается равным приоритету процесса, пославшего сообщение. Более подробно об этом говорится в разделе "Диспетчеризация процессов" главы "Микроядро".
Временные файлы
QNX предусматривает возможность открытия временных файлов, т.е. файлов, которые записываются и затем читаются в течение короткого промежутка времени. Для таких файлов Менеджер файловой системы старается хранить блоки данных в кэш-буфере и производит запись блоков на диск только в случае крайней необходимости.
Псевдодиски
Менеджер файловой системы содержит встроенную возможность поддержки электронного диска, позволяющую использовать до 8 Мегабайт оперативной памяти в качестве псевдодиска. Так как Менеджер файловой системы использует высокоэффективный механизм составных сообщений, то данные из псевдодиска копируются непосредственно в приложение.
Менеджер файловой системы в состоянии обойти кэширование, так как псевдодиск является встроенным, а не реализован как отдельный драйвер. Для информации об обмене составными сообщениями, смотри раздел "Дополнительные возможности" в главе "Микроядро".
Так как псевдодиски исключают аппаратные задержки и не используют кэширование данных, поэтому они обеспечивают больший детерминизм при выполнении операций ввода/вывода по сравнению с жесткими дисками.
Надежность файловой системы
В QNX высокая производительность файловой системы достигается не за счет снижения надежности. Это обеспечивается несколькими способами.
В то время как большая часть данных помещается в кэш-буфер и записывается с небольшой задержкой, критические для файловой системы данные записываются немедленно. Обновления каталогов, индексных дескрипторов (inodes), блоков экстентов и битовой карты производятся без задержки, чтобы гарантировать целостность структуры файловой системы на диске (т.е. что не будет внутреннего несоответствия данных на диске).
Иногда все перечисленные выше структуры данных должны быть обновлены. Например, если вы перемещаете файл в каталоге, последний экстент которого заполнен, то каталог должен вырасти. В таких случаях порядок операций тщательно подобран таким образом, что даже если произойдет катастрофический сбой в момент, когда операция еще не полностью завершена (например, отключение питания), то файловая система после перезапуска все же сохранит работоспособность. В худшем случае, некоторые блоки будут выделены, но не использованы. Исправить подобную ситуацию можно, запустив утилиту chkfsys.
Восстановление файловой системы
Даже самые надежные системы не застрахованы от аварийных ситуаций, таких как:
- появление плохих блоков на диске в результате бросков или провалов напряжения;
- неумелый или злонамеренный пользователь, имеющий доступ к привилегиям администратора системы, выполнил инициализацию файловой системы (утилитой dinit);
- некорректная программа (в особенности, выполняющаяся не в среде QNX) игнорирует информацию о разделах диска и перезаписывает часть раздела QNX.
Чтобы после таких ситуаций можно было восстановить как можно больше файлов, на диск записываются уникальные "сигнатуры" для автоматической идентификации и восстановления критических частей файловой системы. Файл с индексными дескрипторами (/.inodes), так же как и каждый каталог, и блок экстентов, все содержат уникальные образцы данных, которые могут быть использованы утилитой chkfsys для восстановления серьезно поврежденной файловой системы.
Более подробная информация о восстановлении файловой системы содержится в документации к утилите chkfsys.
Работа с дисками
Менеджер файловой системы управляет блок-ориентированными файлами. Эти файлы определяют диски и разделы дисков.
Диски и дисковые подсистемы
QNX считает каждый физический диск на компьютере блок-ориентированным файлом. Как блок-ориентированный файл, диск рассматривается файловой системой QNX как последовательность блоков размером по 512 байт, независимо от размера диска. Блоки нумеруются, начиная с первого блока на диске (блок 1).
Так как каждый диск является блок-ориентированным файлом, он может быть открыт как одно целое для низкоуровневого доступа с использованием стандартных POSIX Си функций, таких как open(), read(), write() и close(). На уровне блок-ориентированного файла, который определяет целый диск, QNX не делает абсолютно никаких предположений о каких-либо структурах данных, которые могут существовать на диске.
Компьютер под управлением QNX может иметь одну или несколько дисковых подсистем. Каждая дисковая подсистема состоит из контроллера и одного или более дисков. Вы запускаете драйвер устройства для каждой дисковой подсистемы, которая должна управляться Менеджером файловой системы.
Разделы ОС
QNX соответствует промышленному стандарту де-факто, который позволяет различным операционным системам разделять один и тот же физический диск. В соответствии с этим стандартом, таблица разделов может определять до четырех первичных разделов на диске. Таблица хранится в первом блоке диска.
Каждый раздел должен иметь "тип", узнаваемый операционной системой, которая должна использовать этот раздел. Следующий список содержит используемые на данный момент типы разделов:
| Тип: | Операционная система |
| 1 |
DOS (12-битная FAT) |
| 4 |
DOS (16-битная FAT; разделы <32Mбайт) |
| 5 |
Расширенный раздел DOS |
| 6 |
DOS 4.0 (16-битная FAT; раздел >=32Mбайт) |
| 7 |
OS/2 HPFS |
| 7 |
Предыдущая версия QNX 2 (до 1988) |
| 8 |
QNX 1.x и 2.x ("qny") |
| 9 |
QNX 1.x и 2.x ("qnz") |
| 11 |
DOS 32-битная FAT; разделы до 2047Gбайт |
| 12 |
То же, что тип 11, но использует LBA расширения прерывания Int 13h |
| 14 |
То же, что тип 6, но использует LBA расширения прерывания Int 13h |
| 15 |
То же, что тип 5, но использует LBA расширения прерывания Int 13h |
| 77 |
QNX POSIX раздел |
| 78 |
QNX POSIX раздел (вторичный) |
| 79 |
QNX POSIX раздел (вторичный) |
| 99 |
UNIX |
Если вы хотите иметь несколько разделов QNX 4.x на одном физическом диске, вам следует использовать тип 77 для первого QNX раздела, тип 78 для второго QNX раздела, и тип 79 для третьего. Вы можете использовать другие типы для второго и третьего QNX разделов, но 78 и 79 предпочтительнее. Чтобы пометить любой из этих разделов как загрузочный, используйте утилиту fdisk.
Во время загрузки, загрузчик QNX (опционально устанавливаемый утилитой fdisk) позволяет выбирать в таблице разделов в качестве загрузочного другой раздел, не являющийся загрузочным по умолчанию.
Вы можете использовать утилиту fdisk для создания, модификации или удаления разделов.
Так как QNX рассматривает каждый раздел на диске как блок-ориентированный файл, то это дает возможность доступа к следующему:
- диску целиком, игнорируя разделы, как к блок-ориентированному файлу;
- отдельному разделу как к блок-ориентированному файлу; этот блок-ориентированный файл будет подмножеством блок-ориентированного файла, который определяет весь диск.
Два физических диска. Первый содержит DOS, QNX и UNIX разделы. Второй диск имеет DOS и QNX разделы.
Определение блок-ориентированный файлов
Имена всех блок-ориентированных файлов помещаются в дерево префиксов того компьютера, на котором расположены блок-ориентированные файлы (дерево префиксов рассматривается в главе "Пространство имен ввода/вывода"). Когда запускается драйвер контроллера дисков, Менеджер файловой системы автоматически регистрирует префиксы, которые определяют блок-ориентированный файл для каждого физического диска, подключенного к контроллеру. Утилита mount используется для того, чтобы зарегистрировать префикс для блок-ориентированного файла для каждого раздела на диске.
Пусть, например, у вас имеется стандартный контроллер Western Digital, к которому подключены два диска. На одном диске вы хотите смонтировать раздел DOS, раздел QNX и раздел UNIX. На другом диске вы хотите смонтировать раздел DOS и раздел QNX.
Менеджер файловой системы определит блок-ориентированные файлы /dev/hd0 и /dev/hd1 для двух дисков, подключенных к контроллеру.
Затем вы используете утилиту mount, чтобы определить блок-ориентированный файл для каждого раздела. Например:
mount -p /dev/hd0 -p /dev/hd1
определит следующие блок-ориентированные файлы:
| Раздел ОС: | Блок-ориентированный файл: |
| Раздел DOS на диске hd0 |
/dev/hd0t4 |
| Раздел QNX на диске hd0 |
/dev/hd0t77 |
| Раздел UNIX на диске hd0 |
/dev/hd0t99 |
| Раздел DOS на диске hd1 |
/dev/hd1t4 |
| Раздел QNX на диске hd1 |
/dev/hd1t77 |
Заметьте, что обозначение tn используется для обозначения разделов на диске, используемых определенными операционными системами. Например, раздел DOS обозначается t4, раздел UNIX - это t99 и т.д.
Монтирование файловой системы
Обычно файловая система QNX монтируется на блок-ориентированном файле. Для этого вы снова используете утилиту mount - она позволяет задать префикс, который идентифицирует файловую систему. Например:
mount /dev/hd0t77 /
монтирует файловую систему с префиксом / на разделе, который определен блок-ориентированным файлом с именем hd0t77.
|
Если диск разбит на разделы, то вы должны смонтировать блок-ориентированный файл для раздела QNX 4.x (например /dev/hd0t77), а не основной блок-ориентированный файл, который определяет весь диск (например, /dev/hd0). Если вы попытаетесь смонтировать основной блок-ориентированный файл для всего диска, то при попытке доступа к файловой системе получите сообщение "corrupt filesystem" (поврежденная файловая система). |
Демонтирование файловой системы
Чтобы демонтировать файловую систему, используйте утилиту umount. Так, например, следующая команда демонтирует файловую систему на первичном разделе QNX:
umount /dev/hd0t77
После того, как файловая система демонтирована, файлы в этом разделе уже не доступны.
Ключевые компоненты QNX раздела
В начале каждого раздела QNX располагаются следующие ключевые компоненты:
- блок загрузчика;
- корневой блок;
- битовая карта;
- корневой каталог.
Эти структуры создаются при инициализации файловой системы утилитой dinit.
Структура файловой системы QNX внутри раздела диска.
Блок загрузчика
Это первый физический блок раздела диска. Этот блок содержит код, который загружается и затем исполняется BIOS компьютера для загрузки операционной системы из раздела. Если диск не разбит на разделы (например, гибкий диск), этот блок является первым физическим блоком на диске.
Корневой блок
Корневой блок имеет ту же структуру, что и обычный каталог. Он содержит информацию о четырех особых файлах:
- корневой каталог файловой системы (/)
- файл /.inodes
- файл /.boot
- файл /.altboot
Файлы /.boot и /.altboot содержат образы операционной системы, которые загружаются программой начальной загрузки QNX.
Обычно загрузчик QNX загружает образ ОС, хранящийся в файле /.boot. Но если файл /.altboot не пуст, то вам будет предложена опция загрузки образа, хранящегося в файле /.altboot.
Битовая карта
Чтобы распределять пространство на диске, QNX использует битовую карту, хранящуюся в файле /.bitmap. Этот файл содержит битовую маску для всех блоков на диске, показывающую, какие блоки заняты. Каждому блоку соответствует один бит. Если значение бита 1, то соответствующий блок на диске занят.
Корневой каталог
Корневой каталог раздела ведет себя как обычный каталог, за двумя исключениями:
- как ".", так и ".." являются связями к одной и той же inode информации, а именно, корневым каталогом inode в корневом блоке;
- корневой каталог всегда содержит элементы для файлов /.bitmap, /.inodes, /.boot и /.altboot. Эти элементы предусмотрены для того, чтобы программы, которые выдают информацию о файловой системе, видели эти элементы как обычные файлы.
Менеджер файловой системы DOS
В QNX пространство имен ввода/вывода управляется через префиксы, которые направляют запросы соответствующим процессам-менеджерам. Одним из таких процессов является Менеджер файловой системы DOS (Dosfsys). Dosfsys регистрирует префикс /dos и представляет диски DOS внутри пространства имен QNX как "гостевые" файловые системы.
Dosfsys обеспечивает прозрачный доступ к дискам DOS, так что вы можете рассматривать файловые системы DOS как файловые системы QNX. Такая прозрачность позволяет процессам работать с файлами DOS без каких-либо специальных знаний или действий. Стандартные библиотечные функции ввода/вывода, такие как open(), close(), read() и write() работают с файлом в разделе DOS точно так же, как и с файлом в разделе QNX. Например, чтобы копировать файл из раздела QNX в раздел DOS, достаточно выполнить команду:
cp /usr/luc/file.dat /dos/c/file.dat
Заметьте, что /dos/c - это путь к DOS диску C. Команда cp не содержит какого-либо специального кода для определения, находится ли копируемый файл на диске DOS. Другие команды работают с такой же прозрачностью (например, утилиты cd, ls и mkdir).
Если не существует эквивалента DOS для функции QNX, такой как mkfifo() или link(), то Dosfsys возвращает соответствующий код ошибки (т.е. errno).
Dosfsys работает как с гибкими дисками, так и с разделами жестких дисков. Весь требуемый доступ к диску на низком уровне производится через стандартные функции Менеджера файловой системы. Поэтому, без доступа к коду низкого уровня, Dosfsys способен обеспечить прозрачный интерфейс между приложениями QNX и файловой системой DOS.
Файловая система CD-ROM
Файловая система CD-ROM, Iso9660fsys, обеспечивает прозрачный доступ к носителям CD-ROM, таким образом можно работать с файловыми системами CD-ROM, как будто это файловые системы POSIX. Такая прозрачность обеспечивает процессам доступ к файлам на CD-ROM стандартными средствами.
Менеджер Iso9660fsys реализует стандарт ISO 9660, включая расширения Rock Ridge. Этому стандарту соответствуют компакт-диски DOS и Windows. В дополнение к обычным файлам, Iso9660fsys также поддерживает аудио.
Файловая система флэш
Менеджер файловой системы флэш Efsys.* был специально разработан для работы, как со встроенной, так и со сменной флэш-памятью. Файлы, записанные на сменные носители флэш (карты PC-Card), переносимы в другие системы, которые также поддерживают этот стандарт.
Менеджер Efsys.* сочетает функции менеджера файловой системы и драйвера устройства. Так как Efsys.* содержит драйвер устройства, то существуют отдельные версии Efsys.* для различных видов оборудования встраиваемых систем. Например:
- Efsys.explr2 для платы Intel EXPLR2 (с RFA);
- Efsys.elansc400 для платы AMD Elan SC400;
- Efsys.pcmcia для смешанного использования файловых систем флэш и устройств PCMCIA.
Ограничения
Функциональность файловой системы ограничена используемыми устройствами памяти. Например, для устройств ROM файловая система доступна только для чтения.
Для устройств флэш-памяти существуют ограничения на запись файлов. Вы можете только дозаписывать файл. Кроме того, не обновляется время последнего доступа к файлу. В настоящий момент эти ограничения распространяются даже на SRAM устройства.
Восстановление свободного пространства
Менеджер Efsys.* хранит каталоги и файлы, используя связные (связные - имеющие прямые/обратные указатели) списки структур данных, а не блоки фиксированного размера, как на диске, используемые в традиционных файловых системах с вращающимся носителем. При удалении каталога или файла, принадлежащие ему структуры данных помечаются как удаленные, но не стираются, чтобы избежать непрерывного стирания и перезаписи (и тем самым потерь времени на эти операции).
Со временем свободное место закончится, и менеджеру файловой системы придется выполнить восстановление свободного пространства (иногда эту операцию называют еще "уборка мусора"). Во время этой процедуры Efsys.* восстанавливает свободное место, занимаемое удаленными файлами и каталогами. Для проведения этой операции менеджеру файловой системы требуется хотя бы один свободный блок. Утилита mkffs автоматически резервирует для этой цели один блок при создании файловой системы.
Сжатие и распаковка
Менеджер Efsys.* поддерживает распаковку, что увеличивает объем данных, который может храниться на носителе. Распаковка выполняется менеджером файловой системы для приложений прозрачно.
Для этого файлы должны быть, перед запуском утилиты mkffs, предварительно сжаты с помощью утилиты bpe. Если же копировать сжатый файл в уже созданную файловую систему флэш, то он останется сжатым и при чтении.
Доступ к файлам
Если запретить расширения POSIX, то владельцем файлов всегда будет считаться root, а биты режима всегда будут установлены в rwx. Команды chgrp, chmod и chown в этом случае не будут работать.
Монтирование
Может производиться только при инициализации разделов или при запуске менеджера файловой системы.
Доступ на низком уровне
При запуске Efsys.*, он создает для каждого устройства памяти специальный файл в каталоге /dev. В системе с двумя устройствами памяти Efsys.* создаст файлы /dev/skt1 и /dev/skt2. Специальные устройства игнорируют разбиение на разделы, позволяя доступ к носителям на низком уровне.
Доступ к разделу, содержащему образ файловой системы, возможен только на низком уровне (как к "сырому" устройству). Для каждого такого раздела Efsys.* создает специальный файл вида /dev/sktXimgY, где X - это номер гнезда (socket), а Y - номер раздела на этом носителе.
Файловая система NFS
Первоначально разработанная компанией Sun Microsystems, NFS (Network File System - Сетевая Файловая Система) является TCP/IP приложением, которое с тех пор было реализовано на большинстве DOS и UNIX систем. Его реализация в QNX не заменима для прозрачного доступа к файловым системам других ОС, поддерживающих NFS.
|
QNX изначально поддерживает сетевые файловые системы. Использовать NFS необходимо только для доступа к не-QNX NFS файловым системам, либо если вы хотите открыть NFS-клиентам доступ к файлам QNX. |
NFS позволяет отображать удаленные файловые системы - полностью или частично - в локальное пространство имен. Каталоги на удаленной системе выглядят как часть локальной файловой системы, и все утилиты работы с файлами (ls, cp и mv) работают с удаленными файлами так же, как и с локальными.
|
В QNX 4 для NFS требуется менеджер Socket, который поддерживает сетевые протоколы TCP/IP. Заметьте, что его "облегченный" вариант, Socklet, может использоваться, если не нужна NFS. |
Файловая система SMB
SMBfsys реализует протокол SMB (Server Message Block) совместного использования файлов, который используется различными серверами, такими как Windows NT, Windows 95, Windows for Workgroups, LAN Manager, Samba. SMBfsys обеспечивает QNX-клиенту прозрачный доступ к удаленным дискам таких серверов.
SMBfsys реализует этот протокол, используя только NetBIOS поверх TCP/IP, не NetBEUI. Соответственно, необходимо, чтобы TCP/IP был установлен, как на QNX-машине, так и на удаленном сервере. После того, как запущен SMBfsys и смонтирован удаленный сервер, файловая система сервера появляется в локальном дереве каталог.
|
