именем /usr/bill/file2.



fig: i/dirpath.gif




Путь в структуре каталога QNX к файлу /usr/bill/file2.





Операции с каталогами


Хотя каталог ведет себя во многом как стандартный файл,
Менеджер файловой системы накладывает некоторые ограничения на
операции, которые вы можете производить с каталогом. В частности, вы
не можете открыть каталог для записи либо создать связь для
каталога с помощью функции Си link().


Чтение элементов каталога


Для чтения элементов каталога вы можете использовать набор функций Си,
определенных POSIX, которые обеспечивают не зависимый от ОС доступ к
элементам каталога. Эти функции включают:

  • opendir()
  • readdir()
  • rewinddir()
  • closedir()

Так как каталоги QNX - это просто файлы, содержащие "известную"
информацию, вы можете также читать элементы каталога непосредственно
функциями Си open() и read(). Однако эта техника не
переносима - формат элементов каталога отличается в различных операционных
системах.


Экстенты

В QNX регулярные файлы и файлы каталога хранятся как
последовательность экстентов. Экстент - это непрерывная
последовательность блоков на диске.


Где хранятся экстенты


Файлы, которые состоят только из одного экстента, хранят
информацию об экстенте в элементе каталога. Но, если файл состоит
более чем из одного экстента, информация о расположении экстентов
хранится в одном или более связных блоках экстентов
(связные - имеющие прямые/обратные указатели).
Каждый блок экстентов может содержать информацию не более чем о 60
экстентах.



fig: i/extents.gif




Файл, состоящий из множества непрерывных областей на диске,
называемых в QNX экстентами.





Увеличение файлов


Когда Менеджеру файловой системы необходимо увеличить файл, он
сначала пытается увеличить последний экстент, хотя бы даже на один блок.
Но если последний экстент не может быть дополнен, то для расширения файла
выделяется новый экстент.

Для выделения новых экстентов Менеджер файловой системы использует
метод "первого попадания". Специальная таблица в Менеджере файловой системы
содержит сведения обо всех блоках, описанных в файле /.bitmap (этот
файл описан в секции "Ключевые компоненты раздела
QNX
"). Для каждого блока указывается размер соответствующего ему
свободного экстента. Менеджер файловой системы выбирает из таблицы первый
достаточно большой экстент.



Связи и индексные дескрипторы (inodes)


В QNX файл может обозначаться более чем одним именем. Каждое имя
файла называется связью. В действительности существует два вида
связей: жесткие связи, или просто "связи", и символические связи.
Символические связи описаны в следующей секции.

Для поддержки связей каждого файла, имя файла отделяется от остальной
информации, описывающей файл. Эта информация хранится в структуре,
называемой inode (индексным дескриптором).

Если файл имеет только одну связь (т.е. одно имя), то
блок inode хранится в элементе каталога для этого файла.
Но если файл имеет более чем одну связь, то inode хранится
как запись в специальном файле /.inodes, а элемент
каталога для файла содержит указатель на запись inode.

Учтите, что вы можете создать связь для файла, только если файл и
связь находятся в одной и той же файловой системе.



fig: i/twolinks.gif




Один и тот же файл обозначен двумя связями с именами "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

Figure showing two nodes using symbolic links





Если вы хотите:
Используйте утилиту:
Создать символическую связь
ln (с опцией -s)
Удалить символическую связь*
rm
Узнать, является ли файл символической связью
ls

* Помните, что удаление символической связи действует только
на связь, а не на адресуемый объект


Некоторые функции оперируют непосредственно с символическими
связями. Для этих функций замена обозначения связи в пути на ее
содержимое не производится. К этим функциям относятся unlink()
(которая удаляет символическую связь), lstat() и readlink().

Так как символические связи могут указывать на каталоги, то неверная
конфигурация может привести к проблемам, таким, как циклические
связи. Чтобы защититься от циклических связей, система накладывает
ограничения на количество переходов; этот предел определен как
SYMLOOP_MAX во включаемом файле <limits.h>.



Программные каналы (pipes) и FIFO



Программные каналы (pipes)

Программный канал - это неименованный файл, который служит
как канал ввода/вывода между двумя или более взаимодействующими процессами -
один процесс пишет в программный канал, другой читает из программного
канала. Менеджер файловой системы обеспечивает буферизацию данных. Размер
буфера определен как PIPE_BUF в файле <limits.h>.
Программный канал удаляется после того как закрыты оба его конца.

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

Типичное применение программного канала
состоит в соединении вывода одной программы с вводом другой программы.
Это соединение часто производится командным интерпретатором (Shell).
Например:

ls | more

направляет стандартный вывод от утилиты ls через
программный канал в стандартный ввод утилиты more.




Если вы хотите:
Используйте:
Создать программный канал из командного интерпретатора
Символ программного канала ("|")
Создать программный канал из программы
Функции pipe() или popen()







Note: На бездисковых рабочих станциях вы можете запустить Менеджер
программных каналов (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 рассматривает каждый раздел на диске как
блок-ориентированный файл, то это дает возможность доступа к следующему:

  • диску целиком, игнорируя разделы, как к блок-ориентированному
    файлу;

  • отдельному разделу как к блок-ориентированному файлу; этот
    блок-ориентированный файл будет подмножеством блок-ориентированного
    файла, который определяет весь диск.



fig: i/twodisks.gif




Два физических диска. Первый содержит 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.







Note: Если диск разбит на разделы, то вы должны смонтировать
блок-ориентированный файл для раздела QNX 4.x (например /dev/hd0t77),
а не основной блок-ориентированный файл, который определяет весь диск
(например, /dev/hd0). Если вы попытаетесь смонтировать основной
блок-ориентированный файл для всего диска, то при попытке доступа к
файловой системе получите сообщение "corrupt filesystem" (поврежденная
файловая система).





Демонтирование файловой системы

Чтобы демонтировать файловую систему, используйте утилиту umount.
Так, например, следующая команда демонтирует файловую систему на
первичном разделе QNX:

umount /dev/hd0t77

После того, как файловая система демонтирована, файлы в этом
разделе уже не доступны.



Ключевые компоненты QNX раздела


В начале каждого раздела QNX располагаются следующие ключевые
компоненты:

  • блок загрузчика;
  • корневой блок;
  • битовая карта;
  • корневой каталог.

Эти структуры создаются при инициализации файловой системы
утилитой dinit.



fig: i/qnxpart.gif




Структура файловой системы 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 без каких-либо специальных знаний или действий. Стандартные библиотечные