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

Введение
Классы файловых систем
Образная файловая система
"Файловая система" в ОЗУ
Файловая система ETFS
Файловая система QNX4
Файловая система Power-Safe
Файловая система DOS
Файловая система CD-ROM
Файловая система FFS3
Файловая система NFS
Файловая система CIFS
Файловая система Ext2 для ОС Linux
Файловая система UDF
Файловые системы HFS и HFS Plus
Файловая система NTFS
Виртуальные файловые системы

Введение

В ОС QNX Neutrino поддерживается большое число различных файловых систем. Как и большинство процессов, реализующих в ОС QNX Neutrino те или иные службы, файловые системы работают вне ядра. Приложения используют файловые системы посредством обмена сообщениями, которые генерируются с помощью программного интерфейса POSIX на основе разделяемых библиотек.

В архитектуре ОС QNX Neutrino большинство из этих файловых систем представляют собой администраторы ресурсов. Каждая файловая система получает свою область в пространстве имен путей (называемую точкой монтирования) и предоставляет свои службы посредством стандартного программного интерфейса POSIX (open(), close(), read(), write(), lseek() и т. д.). Администраторы ресурсов файловой системы получают точку монтирования и управляют структурой каталогов ниже этой точки. Они также проверяют отдельные компоненты путевых имен на уровень разрешений и доступа.

Такая схема реализации имеет следующие преимущества:

файловые системы можно запускать и останавливать динамически;

множество файловых систем могут работать одновременно;

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

файловая система, которая используется на одном узле, является прозрачной для доступа с других узлов.

Файловые системы и разрешение имен путей

Любую службу или файловую систему, которая зарегистрирована администратором процессов, можно бесшовным образом локализовать и присоединить. Когда администратор ресурсов файловой системы регистрирует точку монтирования, администратор процессов создает для нее запись во внутренней таблице монтирования с указанием идентификатора соответствующего сервера (т. е. в записи указываются идентификаторы nd, pid, chid).

Эта таблица в действительности объединяет несколько каталогов файловой системы так, что пользователь воспринимает их как один каталог. Администратор процессов обрабатывает ту часть путевого имени, которая соответствует точке монтирования, а администраторы ресурсов файловых систем обрабатывают оставшиеся части имени пути. Файловые системы могут регистрироваться (т. е. монтироваться) в любом порядке.

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

Если путевое имя означает каталог, администратор процессов запрашивает список файлов в этом каталоге у всех файловых систем, которые могут разрешить данное имя пути по вызову функции readdir(). Если имя пути не является каталогом, тогда обращение делается к первой файловой системе, которая смогла выполнить разрешение этого имени.

Более подробные сведения о разрешении путевых имен можно найти в разделе "Управление пространством имен" главы "Администратор процессов".

Классы файловых систем

Файловые системы можно разделить на несколько классов.

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

Блочная. Традиционная файловая система, которая работает с блочными устройствами типа жестких дисков и приводов CD-ROM. К этому классу относятся файловые системы QNX4, DOS и CD-ROM.

Файловая система во флеш-памяти. Эта файловая система не является блок-ориентированной и предназначена специально для устройств с флеш-памятью. Для NOR-устройств следует использовать файловую систему FFS3, для NAND-устройств — ETFS.

Сетевая. Предоставляет сетевой доступ к файловым системам, находящимся на удаленных компьютерах. К этому классу относятся файловые системы NFS и CIFS (SMB).

Виртуальная. ОС QNX Neutrino предоставляет файловую систему Inflator, который является администратором ресурсов, стоящим перед другими файловыми системами и выполняющим распаковку предварительно сжатых файлов (с помощью утилиты deflate).

Файловые системы как разделяемые библиотеки

Так как в ОС QNX Neutrino часто используется несколько файловых систем одновременно, их разработали в виде семейства драйверов и разделяемых библиотек для того, чтобы расширить возможности их повторного использования. В результате добавление новых файловых систем, как правило, требует меньше затрат, чем можно было бы ожидать.

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

ОС QNX Neutrino имеет следующую иерархию файловых систем — рис. 9.1.

Рис. 9.1. Иерархия файловых систем в ОС QNX Neutrino

Как видно из рис. 9.1, файловые системы, драйверы дисков и модуль io-blk реализуются в виде разделяемых библиотек, которые, по сути, представляют собой пассивные блоки программного кода, находящиеся резидентно в памяти, в то время как модуль io-cam является активным исполняемым модулем, который обращается к этим библиотекам. Процесс io-cam запускается первым и вызывает разделяемую библиотеку блочного уровня (block-level shared library) (io-blk.so) и разделяемые библиотеки дисковых драйверов (devb-*). Позже могут быть динамически загружены разделяемые библиотеки, реализующие файловую систему, чтобы обеспечить соответствующий интерфейс и службы файловых систем.

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

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

io-blk

Работа большинства разделяемых библиотек файловых систем основана на модуле блочного ввода/вывода (io-blk). Этот модуль также действует в качестве администратора ресурсов и объявляет блок-ориентированный файл (block-special file) для каждого физического устройства. В системе с двумя жесткими дисками по умолчанию будут использоваться следующие файлы:

/dev/hd0 — первый жесткий диск;
/dev/hd1 — второй жесткий диск.

Эти файлы отображают каждый диск с линейным доступом и к ним можно обращаться с помощью всех стандартных POSIX-примитивов для работы с файлами (open(), close(), read(), write(), lseek() и т. д.). Хотя модуль io-blk поддерживает 64-битное смещение для операций позиционирования, интерфейс драйвера является 32-битным, что позволяет работать с 2-терабайтными дисками.

Встроенный RAM-диск

Модуль io-blk поддерживает работу с внутренними RAM-дисками, которые можно создать посредством задания специальной опции командной строки (blk ramdisk=size). Поскольку RAM-диск создается не дополнительным драйвером устройства (например, devb-ram), а является внутренним по отношению к модулю, его производительность значительно выше, чем у специального драйвера RAM-дисков.

Поскольку RAM-диск реализуется на уровне модуля io-blk, память данных этого устройства работает синхронно с основным кешем, в результате чего операции ввода/вывода могут выполняться без помощи буферного кеша, что избавляет от необходимости копировать память и в то же время сохраняет когерентность кеша (coherency). При сравнении этого подход с другим, а именно с реализацией на уровне драйвера (например, devb-ram), при которой прозрачное отображение памяти в виде блочного устройства требует копирования и дублирования данных посредством буферного кеша. Межбиблиотечные вызовы (inter-DLL callouts) также исключаются. Кроме того, этот метод дает преимущество с точки зрения занимаемого объема ОЗУ для систем, в которых кроме жесткого диска еще требуется псевдодиск, — в этом случае может использоваться один общий драйвер.

Дисковые разделы

ОС QNX Neutrino поддерживает общепринятый промышленный стандарт разбиения дисков на разделы. Такое разбиение позволяет использовать несколько файловых систем на одном физическом диске. Каждый раздел представляется в виде блок-ориентированного файла, а тип раздела добавляется к файловому имени диска, на котором он находится. В приведенном ранее примере с двумя дисками, если первый диск имеет раздел QNX и раздел DOS, а второй диск имеет только раздел QNX, то по умолчанию диски будут содержать следующие файлы:

/dev/hd0 — первый жесткий диск;
/dev/hd0t6 — раздел DOS на первом жестком диске;
/dev/hd0t77 — раздел QNX на первом жестком диске;
/dev/hd1 — второй жесткий диск;
/dev/hd1t77 — раздел QNX на втором жестком диске.

В табл. 9.1 приведены некоторые часто используемые типы разделов.

Таблица 9.1. Типы разделов

Тип	Файловая система
1	DOS (FAT12)
4	DOS (FAT16, разделы не более 32 Мбайт)
5	Расширенный раздел DOS
6	DOS 4.0 (FAT16, разделы от 32 Мбайт)
7	OS/2 HPFS^*
7	Предыдущая версия QNX 2 (до 1988 г.)
7	Windows NT
8	QNX 1.x и 2.x (qny)
9	QNX 1.x и 2.x (qnz)
11	FAT32 для DOS (разделы до 2047 Гбайт)
12	Аналогична типу 11, но с использованием расширений Logical Block Address Int 13h
14	Аналогична типу 6, но с использованием расширений Logical Block Address Int 13h
15	Аналогична типу 5, но с использованием расширений Logical Block Address Int 13h
78	Раздел QNX POSIX (вторичный)
79	Раздел QNX POSIX (вторичный)
77	Раздел QNX POSIX
99	UNIX
131	Linux (Ext2)
175	Apple Macintosh HFS или HFS Plus
177	QNX Power-Safe POSIX partition (вторичный)
178	QNX Power-Safe POSIX partition (вторичный)
179	QNX Power-Safe POSIX partition

^*HPFS (High Performance File System) – высокопроизводительная файловая система, название файловой системы для OS/2.

Буферный кеш

Разделяемая библиотека io-blk реализует буферный кеш (buffer cache), который наследуется всеми файловыми системами. Буферный кеш предназначен для сохранения часто используемых блоков файловой системы для того, чтобы уменьшить число выполняемых файловой системой физических операций дискового ввода/вывода.

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

Критические блоки файловой системы (блоки битовой карты (bitmap blocks), каталоговые блоки, блоки экстентов (extent blocks) и блоки индексных дескрипторов (inode blocks)) записываются на диск немедленно и синхронно.

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

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

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

В табл. 9.2 показано, какие из служб, определенных стандартом POISX, поддерживаются в разных файловых системах.

Таблица 9.2. Службы и файловые системы

Файловая система	Дата доступа	Дата изменения	Дата изменения статуса	Длина имени файла^a	Права доступа	Каталоги	Жесткие связи (hard links)	Символьные связи (soft links)	Декодирование при чтении
Образная	Нет	Нет	Нет	255	Да	Нет	Нет	Нет	Нет
RAM	Да	Да	Да	255	Да	Нет	Нет	Нет	Нет
ETFS	Да	Да	Да	91	Да	Да	Нет	Да	Нет
QNX4	Да	Да	Да	48^b	Да	Да	Да	Да	Нет
Power-Safe	Да	Да	Да	510	Да	Да	Да	Да	Нет
DOS	Да^c	Да	Нет	8.3^d	Нет	Да	Нет	Нет	Нет
NTFS	Да	Да	Нет	255	Нет	Да	Нет	Нет	Да
CD-ROM	Да^e	Да^e	Да^e	207^f	Да^e	Да	Нет	Да^e	Нет
UDF	Да	Да	Да	254	Да	Да	Нет	Нет	Нет
HFS	Да	Да	Да	255^g	Да	Да	Нет	Нет	Нет
FFS3	Нет	Да	Да	255	Да	Да	Нет	Да	Да
NFS	Да	Да	Да	– ^h	Да^h	Да	Да^h	Да^h	Нет
CIFS	Нет	Да	Нет	– ^h	Да^h	Да	Нет	Нет	Нет
Ext2	Да	Да	Да	255	Да	Да	Да	Да	Нет

^aДля внутреннего представления файловых имен используется кодировка UTF-8, которая использует различное количества байт для одного символа. Многие дисковые форматы используют для этих целей кодировку UCS2, в которой каждый символ имеет фиксированный размер (2 байта). Длины для файловых систем QNX 4, Power-Safe и EXT2 указаны в байтах, а для NTFS, HFS, UDF, CD/Joliet и DOS/VFAT — в символах.

^b505 если включено .longfilenames; в противном случае, 48.

^cVFAT или FAT32 (например, Windows 95).

^d255 - VFAT или FAT32 (например, Windows 95).

^e— с расширениями Rock Ridge.

^f103 с расширениями Joliet; 255 – с расширениями Rock Ridge.

^g31 на HFS.

^h– ограничение удаленной файловой системой.

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

Каждый образ в ОС QNX Neutrino представляет собой простую файловую систему, предназначенную только для чтения, которая отображает набор файлов, встроенных в образ ОС.

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

"Файловая система" в ОЗУ

В каждой системе QNX есть простая "файловая система" в ОЗУ (RAM filesystem), которая позволяет размещать файлы чтения/записи в каталог /dev/shmem.

Примечание. Обратите внимание, что /dev/shmem в действительности не является файловой системой. Это обладающее некоторыми характеристиками, похожими на файловую систему, окно к именам объектов разделяемой памяти.

Файловая система в ОЗУ находит наибольшее применение в миниатюрных встраиваемых системах, для которых не требуются постоянные запоминающие устройства, чтобы выполнять перезагрузку, но необходима компактная, быстродействующая файловая система с минимальными функциональными возможностями на основе временного запоминающего устройства.

Такая файловая система входит в состав модуля procnto и не требует какой-либо настройки. С ее помощью можно создавать файлы в каталоге /dev/shmem и увеличивать их до любого размера в зависимости от ресурсов ОЗУ.

Хотя файловая система в ОЗУ не поддерживает ни жестких, или символьных, связей, ни каталогов, можно создать ссылку на нее с помощью механизма ссылок, предоставляемого администратором процессов. Например, можно создать связь с каталогом /tmp, находящимся в ОЗУ:

ln -sP /dev/shmem /tmp

Эта команда указывает модулю procnto связать администратор процессов с каталогом /dev/shmem, который обозначен как /tmp. В результате приложения могут открывать файлы в каталоге /tmp, как будто это обычная файловая система.

Замечание

Для того чтобы минимизировать объем кода файловой системы в ОЗУ, реализованного внутри администратора процессов, из этой файловой системы были исключены такие присущие обычным файловым системам функции, как блокировка файлов и создание каталогов.

Файловая система ETFS

Встраиваемая транзакционная файловая система (Embedded transaction filesystem, ETFS) является высоконадежной файловой системой, предназначенной для устройств с полупроводниковой памятью, и в частности флеш-памяти типа NAND (рис. 9.2). Эта файловая система поддерживает полностью иерархическую структуру каталогов с POSIX-семантикой (см. табл. 9.2).

Файловая система ETFS целиком основана на механизме транзакций (transactions). Каждая операция записи (пользовательских данных или метаданных файловой системы) состоит из выполнения транзакции. Транзакция может быть успешно выполнена только целиком. В противном случае считается, что она вообще не выполнялась.

При выполнении транзакций никогда не производится перезапись обновляемых (live) данных. Если запись происходит во время обновления файла или каталога, то она всегда выполняется в другой, свободной области. Таким образом, если в момент выполнения операции случается какой-либо сбой (например, из-за отказа системы или потери электропитания), старые данные остаются в сохранности.

Принцип запрета на перезапись обновляемых данных также используется в некоторых журналируемых (log-based) файловых системах. Однако в файловой системе ETFS этот принцип реализуется радикальным образом, так как в журнал транзакций заносятся абсолютно все операции. Иерархическая структура файловой системы выстраивается "на лету" посредством обработки журнала транзакций, связанного с соответствующим устройством. Сканирование файловой системы производится при запуске, но при этом только небольшая часть данных используется для чтения и CRC-проверки^⁷, что ускоряет загрузку, не снижая надежности.

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

Это хорошо подходит для флеш-памяти NAND, так как в ней бывают дефектные блоки, которые специальным образом помечаются производителем и могут встречаться в любой области.

Рис. 9.2. Файловая система ETFS, целиком основанная на механизме транзакций

Структура транзакции

Каждая транзакция состоит из заголовка и последующего блока данных. В заголовке содержится следующая информация:

FID — уникальный идентификатор файла, которому принадлежит транзакция;
смещение — смещение блока данных внутри файла;
размер — размер блока данных;
последовательность — монотонно возрастающее число, используемое для упорядочивания по времени;
CRC-код — число для проверки целостности данных (для флеш-памяти типа NAND, NOR и SRAM);
ECC-код^⁸ — код коррекции ошибок (для флеш-памяти типа NAND);
другая информация — зарезервировано.

Типы устройств хранения данных

Хотя файловая система ETFS лучше всего подходит для устройств хранения данных типа NAND, она поддерживает также и другие типы встраиваемых сред хранения с помощью следующих классов драйверов — табл. 9.3.

Таблица 9.3. Классы драйверов

Класс	CRC	ECC	Выравнивание износа по стиранию (wear-leveling erase)	Выравнивание износа по чтению (wear-leveling read)	Размер кластера
NAND 512+16	Да	Да	Да	Да	1 Кбайт
NAND 2048+64	Да	Да	Да	Да	2 Кбайт
RAM	Нет	Нет	Нет	Нет	1 Кбайт
SRAM	Да	Нет	Нет	Нет	1 Кбайт
NOR	Да	Нет	Да	Нет	1 Кбайт

Замечание

Хотя файловая система ETFS может поддерживать флеш-память типа NOR, рекомендуется применять файловую систему FFS3 (devf-*), которая разработана специально для этого типа флеш-памяти.

Обеспечение отказоустойчивости

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

выравнивание динамического износа (dynamic wear-leveling);
выравнивание статического износа (static wear-leveling);
выявление ошибок по CRC-коду;
исправление ошибок по ECC-коду;
контроль количества операций чтения и автоматическое обновление (read degradation monitoring with automatic refresh);
откат транзакций (transaction rollback);
атомарные операции с файлами;
автоматическая дефрагментация файлов.

Выравнивание динамического износа

Каждый блок флеш-памяти допускает ограниченное количество безотказных циклов стирания, которое не превышает 100 000. Файловая система ETFS ведет подсчет количества стираний по каждому блоку памяти для того, чтобы учитывать их износ при выборе блоков памяти для использования и попытаться равномерно распределить нагрузку между ними. Это позволяет значительно увеличить срок службы устройства. Разница может быть весьма ощутимой: без выравнивания износа сбой может произойти в течение нескольких дней, а при его использовании может быть обеспечена безотказная работа в течение более чем 40 лет.

Выравнивание статического износа

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

Файловая система ETFS отслеживает статичные блоки с низким износом и перемещает данные из них в блоки с повышенным износом. Это позволяет решить две проблемы: во-первых, интенсивно используемые блоки флеш-памяти получают отдых, поскольку теперь содержат статичные данные, а во-вторых, статичные блоки флеш-памяти, которые используются менее интенсивно, получают большую нагрузку.

Выявление ошибок по CRC-коду

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

Исправление ошибок по ECC-коду

При обнаружении ошибки по CRC-коду файловая система ETFS может применить код исправления ошибки (ECC-код) для восстановления данных. Исправление ошибок по ECC-коду используется для флеш-памяти типа NAND, в которой могут случаться ошибки в одном разряде. Возникновение ECC-кода является сигналом, предупреждающим о том, что блок флеш-памяти, в котором произошла ошибка, возможно, начинает "уставать" (weak), т. е. теряет свой заряд.

Файловая система ETFS отмечает усталый блок для операции обновления, в результате которой данные копируются в другой блок флеш-памяти, а содержание усталого блока стирается, т. е. производится его перезарядка.

Контроль количества операций чтения и автоматическое обновление

Каждая операция чтения внутри блока флеш-памяти типа NAND приводит к ослаблению заряда, с помощью которого хранятся данные. Большинство устройств обеспечивают до 100 000 гарантированных операций чтения. ECC-код позволяет исправлять ошибки в одном бите, но при ошибках во множестве битов этот код может оказаться бесполезным.

В файловой системе ETFS эта проблема решается следующим образом: файловая система отслеживает операции чтения и периодически обновляет блоки памяти до того, как количество операций превысит установленный предел 100 000.

Откат транзакций

При запуске файловой системы ETFS она обрабатывает все транзакции и откатывает (отменяет) последние частично выполненные или не успешные транзакции. Программный код, который реализует операцию отката, разработан таким образом, что даже при сбое электропитания, произошедшем в момент операции отката, попытка ее выполнения будет предпринята вновь после перезагрузки, что позволяет системе восстанавливаться даже после множественных последовательных сбоев. Необходимость выполнения транзакции в каждом случае проверяется по CRC-коду.

Атомарные операции с файлами

Файловая система ETFS реализует очень простую структуру каталогов, которая позволяет выполнять значительные изменения по одной операции записи. Например, перемещение файла или каталога в другой каталог в большинстве файловых систем представляет собой многоэтапную операцию. В файловой системе ETFS такое перемещение осуществляется посредством единственной операции записи.

Автоматическая дефрагментация файлов

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

Файловая система QNX4

Файловая система QNX4 (fs-qnx4.so) является высокопроизводительной и использует ту же дисковую структуру, что и QNX 4.

Файловая система QNX4 имеет чрезвычайно высокую степень отказоустойчивости благодаря использованию экстент-ориентированной схемы распределения блоков на основе битовой карты (extent-based, bitmap allocation scheme), а также применению специализированных подписей, которые обеспечивают защиту от потерь данных и возможность быстрого восстановления. Эта экстент-ориентированная файловая система обладает следующими особенностями:

соответствие стандарту POSIX;
отказоустойчивость (вся важная служебная информация записывается на диск, минуя кеш);
дисковые "подписи" и специальная информация для быстрого восстановления данных при сбоях диска;
длина файловых имен до 505 символов;
многопоточность;
приоритет, управляемый клиентом;
дисковый формат, аналогичный файловой системе в QNX 4.

Замечание

После выхода версии 6.2.1 48-символьное ограничение на имена файлов было увеличено до 505 символов посредством обратно-совместимого расширения. Прежний дисковый формат был сохранен, поэтому новые системы смогут определять длинные имена, тогда как старые системы — только урезанные 48-символьные имена.

Более подробные сведения об этой файловой системе можно найти в документе «ЗОСРВ «Нейтрино». Руководство системного программиста (администратора). КПДА.10964-01 32», в разделе "Файловая система QNX4".

Файловая система Power-Safe

Файловая система Power-Safe, известная так же как файловая система QNX6, поддерживается менеджером fs-qnx6.so, реализованным в виде разделяемого объекта. Это надежная дисковая файловая система, которая выдерживает сбои по питанию без потерь или повреждений данных. Она разработана для традиционных вращающихся жестких дисковых накопителей.

Проблемы с существующими дисковыми файловыми системами

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

• На жестком диске каждый сектор содержит четырехбайтный код коррекции ошибок (error-correcting code — ECC), который используется дисководом для обнаружения аппаратных ошибок. Если питание пропадает в тот момент, когда драйвер выполняет запись на диск, то головки убираются во избежание удара по магнитной поверхности, оставляя сектор с частично записанными новыми данными. При следующей попытки чтения этого блока — или сектора — некорректный ECC приведет к ошибке чтения, поэтому будут потеряны и старые и новые данные.

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

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

• Для проверки целостности файловой системы QNX4 используется утилита chkfsys, однако она проверяет только структуры и метаданные файловой системы, а не пользовательские данные. Кроме того, она может достаточно долго проверять большие диски или диски с большим количеством каталогов.

• При повреждении корневого каталога, битовой карты или файла inode (все они расположены в нескольких первых блоках диска) монтирование файловой системы станет невозможным. При этом может сохраняться возможность восстановления диска «вручную», но это требует от инженера глубоких знаний структуры данной файловой системы.

Файловая система COW

Для решения проблем, связанных с существующими файловыми системами, файловая система Power-Safe никогда не перезаписывает актуальные данные; все обновления выполняются методом COW (copy-on-write, копирование-по-записи), формирующим новое представление файловой системы на неиспользованных блоках диска. Новое представление файловой системы становится рабочим только, когда все обновления записаны на диск и целостны. В файловой системе, реализующей COW защищены как метаданные, так и данные пользователя.

Чтобы увидеть, как это действует, необходимо рассмотреть сохранение данных. Файловая система Power-Safe разделена на логические блоки, размер которых можно задавать при использовании mkqnx6fs для форматирования файловой системы. Каждый индексный дескриптор содержит 16 указателей блока. Если файл меньше, чем 16 блоков, индексный дескриптор указывает прямо на данные блока. Если файл слишком большой, эти 16 блоков становятся указателями к другим блокам и т.д.

Все конечные (финальные) блочные указатели на реальные данные расположены в листьях и имеют один и тот же уровень. В некоторых других сиситемах – таких как EXT2 – файл содержит несколько прямых блоков, несколько непрямых, и несколько двойных непрямых, т.о. Перемещение по уровням дейсвует как перемещение по разным частям файла. В файловой системе Power-Safe все данные пользователя в файле находятся на одном уровне.

Рис. 9.3.

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

Рис. 9.4.

Несколько следствий для файловой системы COW:

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

Суперблок – это общий корневой блок, содержащий индексные дескрипторы для битовых карт системы и индексные дескрипторы файлов. Файловая система Power-Safe поддерживает два суперблока:

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

Рабочий супер блок может содержать блоковые указатели на стабильный суперблок. Данные блоки содержат данные, которые еще не изменены, там формируются индексные дескрипторы и битовые карты.

Рис. 9.5.

Снапшот это согласованное представление файловой системы (просто переданный суперблок). Чтобы получить снапшот, файловая система:

блокируется, чтобы убедиться, что она в стабильном состоянии; все клиенты находятся в состоянии ожидания, и нет никаких действий.
Записывает все скопированные блоки на диск. Порядок при этом не важен (для файловой системы QNX), т.о. можно провести оптимизацию.
Принудительно синхронизирует данные на диске, включая содержимое кэша.
Записывает на диск суперблок.
Осуществляет переключение между рабочим и фиксированным представлением. Старые версии скопированных блоков освобождаются и становятся доступными для использования.

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

При этом не нужно запускать chkfsys или воспроизводить журнал сообщений. Время, которое потребуется для монтирования файловой системы – это время считывания связанных блоков.

Предупреждение. Если дисковод не поддерживает синхронизацию, то fs-qnx6.so не может гарантировать устойчивость файловой системы по питанию. Перед тем как использовать данную файловую систему на каком-либо устройстве кроме традиционных вращающихся жестких дисков — такое как устройство USB/Flash — убедитесь, что данные устройство удовлетворяет требованиям файловой системы. Подробнее см. подраздел «Описания программы», посвященный модулю fs-qnx6.so.

Функциональные характеристики

Методы COW имеют следующие недостатки:

каждое изменение данных пользователя, вызывает соответствующие действия с множеством блоков – копирование и изменение, т. к. файловая система никогда не производит изменения индексного дескриптора и непрямых блоковых указателей на месте; файловая система копирует блоки на другое местоположение и изменяет копии. Т.о. операция записи занимает больше времени.

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

Однако:

нет ограничений для порядка в котором будут записаны блоки (не считая суперблока).
новые блоки могут быть распределены на любом свободном, непрерывном пространстве.

Функциональные характеристики зависят от того, какого размера доступный буфер кэша, и от частоты получения снапшотов. Снапшоты происходят периодически (каждые 10 секунд или, как задано опцией snapshot для fs-qnx6.so), также при вызове sync() для целостной файловой системы или fsync() для одного файла.

Примечание. Синхронизация происходит на уровне файловой системы, а не на уровне (конкретных, этих) файлов, так что fsync() зачастую ресурсоёмкая (затратная) операция; файловая система Power-Safe игнорирует флаг O_SYNC.

Также можно отключить снапшоты, при выполнении длительных операций, и промежуточное состояние нежелательно. Например, при копировании очень больших файлов в файловую систему Power-Safe. Утилита cp – это последовательность основных операций:

open(O_CREAT|O_TRUNC) для создания файла
группа действий write() для копирования данных
lose(), chmod() и chown() для копирования метаданных

Если файл настолько большой, что его копирование перекрывает снапшоты, появятся дисковые представления без этого файла, с файлом различной длины (размером) и, наконец с полностью скопированным файлом с его идентификаторами и правами доступа:

Рис. 9.6.

Каждый снапшот в настоящий момент времени просматривает файловую систему (например, при копировании 50 Мб, размер – 50 Мб, и все данные соответствующие 50 Мб будут скопированы и доступны). Если произойдет сбой питания, файловая система перезагрузит наиболее поздний снапшот. Но если у файловой системы нет порядка следования, действия open(), write() и close() – это одна высокоуровневая операция cp. Однако, если нужна высокоуровневая семантика, необходимо отключить снапшоты, на время действия cp, тогда они не будут происходить посреди операции, и если произойдет сбой питания, файл будет или полностью скопирован или не скопирован совсем.

Подробную информацию о использовании данной файловой системы см. в подразделе «Файловая система Power-Safe» раздела «Работа с файловыми системами», «Руководства системного программиста (администратора)».

Файловая система DOS

Файловая система DOS (fs-dos.so) обеспечивает прозрачный доступ к DOS-дискам таким образом, что она может использоваться как файловая система спецификации POSIX. Такая прозрачность обеспечивает нормальную работу процессов с DOS-файлами.

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

Если DOS не имеет своего эквивалента для какой-либо функции POSIX, модуль fs-dos.so либо вернет ошибку, либо предложит наиболее подходящее действие по умолчанию. Например, попытка создания связи с помощью функции link() приведет к возврату соответствующей errno. С другой стороны, при попытке чтения POSIX-времени какого-либо файла модуль fs-dos.so возвратит вместо неподдерживаемого времени время последнего изменения.

Поддержка версий DOS

Программа fs-dos.so поддерживает разделы как на гибких, так и на жестких дисках, созданные в различных версиях DOS — от DOS 2.1 до Windows 98.

Текстовые файлы DOS

В DOS каждая строка в текстовом файле завершается двумя символами (CR/LF), тогда как в POSIX-системах (и большинстве других систем) каждая строка завершается одним символом (LF). Следует отметить, что модуль fs-dos.so оставляет читаемые текстовые файлы неизменными и не преобразовывает их. Для большинства утилит и программ различие в формате завершения строки не имеет значения.

В некоторых очень старых DOS-программах для обозначения конца файла может использоваться символ <Ctrl>+<Z> (^z). Этот символ также остается без изменений.

Отображение имен файлов в QNX и DOS

В DOS имя файла не может содержать ни один из следующих символов:

/ \ [ ] : * | + = ; , ?

При попытке создать файл с именем, содержащим какой-либо из этих недопустимых символов, будет возникать ошибка. Кроме того, в DOS-именах формата 8.3 все буквенные символы должны быть в верхнем регистре, поэтому при создании файлов модуль fs-dos.so отображает их имена в верхнем регистре. Однако для приложений в ОС QNX Neutrino этот модуль по умолчанию преобразует файловые имена в нижний регистр, поэтому программы и пользователи QNX Neutrino всегда могут видеть и применять имена файлов в нижнем регистре (посредством опции sfn=sfn_mode).

Обработка файловых имен

Администратору fs-dos.so можно задать один из следующих способов обработки длинных файловых имен (посредством опции lfn=lfn_mode):

"игнорировать" — т. е. отображать и создавать только файловые DOS-имена формата 8.3;
"отображать" — применяется для файловых имен, которые длиннее DOS-имен формата 8.3 или содержат комбинацию символов верхнего и нижнего регистров;
всегда создавать как длинные, так и короткие файловые имена.

При использовании опции ignore (игнорировать) можно задать автоматическое (без предупреждения) отсечение символов, превышающих формат 8.3.

Международные кодировки для файловых имен

Файловая система DOS поддерживает "кодовые страницы" DOS (международные наборы символов) для местных кодировок. Короткие файловые имена формата 8.3 сохраняются c помощью определенного набора символов (как правило, наиболее распространенные дополнительные национальные символы содержатся в диапазоне кодов с установленным 8 битом^⁹). В файловой системе DOS поддерживаются все распространенные американские, а также западноевропейские и восточноевропейские кодовые страницы (437, 850, 852, 866, 1250, 1251, 1252). Если необходимо произвести программное обеспечение, которое должно взаимодействовать с различными жесткими дисками с файловыми системами DOS или Windows или предназначено для неанглоязычных пользователей, наличие поддержки этих кодовых страниц обеспечивает переносимость, благодаря которой файловые имена будут создаваться с помощью кодовой таблицы Unicode и местной кодировки и будут доступны как в том, так и в другом виде.

Замечание

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

Метки томов в DOS

В DOS применяются метки тома, которые по сути представляют собой запись в корневом каталоге файловой системы. Для того чтобы отличать метку тома от DOS-каталога, модуль fs-dos.so отображает метку тома в соответствии со значением, заданным для опции vollabel:

игнорировать метку тома;
отображать метку тома как специальный именованный файл (name-special file);
отображать метку тома как специальный именованный файл со знаком равенства (=) в качестве первого символа в имени.

Отображение прав доступа между DOS и QNX

Файловая система DOS поддерживает не все биты разрешения доступа, определенные в спецификации POSIX. Вместо битов READ и WRITE используется бит READ_ONLY. Бит EXECUTE отсутствует. При создании DOS-файла бит READ_ONLY устанавливается при условии, что все биты WRITE спецификации POSIX отключены. Доступ к DOS-файлу производится при условии, что бит READ спецификации POSIX всегда установлен для пользователя, группы и т. д.

Поскольку файл, который не имеет разрешения EXECUTE, не может быть выполнен, администратором fs-dos.so предусмотрена опция (exe=exec_mode), которая позволяет задать способ обработки битов EXECUTE спецификации POSIX.

Права на файлы

Хотя файловая структура DOS не поддерживает пользовательские и групповые идентификаторы, модуль fs-dos.so по умолчанию не возвращает код ошибки при попытке их изменения. Возврат ошибки не предусмотрен, потому что многие утилиты могут пытаться выполнить такое изменение, что может привести к непредсказуемым последствиям. Таким образом, здесь применяется следующий подход: "любые изменения разрешены, так как на диск они все равно не будут записаны".

Опции posix= позволяют применить более строгие условия проверки POSIX, а также включить эмуляцию POSIX. Например, в POSIX-режиме при попытке выполнения какого-либо из следующих действий возникает ошибка EINVAL:

присвоение пользовательского идентификатора или идентификатора группы в значение, отличное от принятого по умолчанию (root);
удаление разрешения r (чтение);
установка разрешения s (смена идентификатора).

Если установить опцию posix в значение emulate (по умолчанию) или strict, это даст следующий результат:

в каталоге root создаются записи . и ..;
вычисляется размер каталога;
вычисляется количество связей в каталоге с учетом его подкаталогов.

Файловая система CD-ROM

Файловая система CD-ROM обеспечивает прозрачный доступ к ресурсам CD-ROM, благодаря чему файловые системы CD-ROM работают так, как если бы они были файловыми системами POSIX. Подобная прозрачность позволяет процессам работать с файлами на CD-ROM без каких-либо дополнительных средств или вычислений.

Администратор fs-cd.so реализует стандарт ISO 9660, а также ряд расширений, в том числе Rock Ridge (RRIP), Joliet (Microsoft) и поддержку дополнительных сессий (Kodak Photo CD, enhanced audio).

Примечание. Менеджер fs-cd.so является устаревшим. Вместо него предпочтительнее использовать менеджер fs-udf.so, который в дополнение к файловой системе UDF поддерживает файловые системы ISO-9660. Подробнее о UDF см. далее в этой главе в подразделе «Файловая система UDF”.

Файловая система FFS3

Драйверы файловой системы FFS3 реализуют POSIX-подобную файловую систему на устройствах с флеш-памятью типа NOR. Эти драйверы являются автономными исполняемыми модулями, которые содержат программный код как для реализации файловой системы во флеш-памяти, так и для реализации работы устройства.

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

Как правило, драйверы обозначаются именем devf-system, где system означает встраиваемую систему. Например, драйвер devf-800fads предназначен для отладочной платы 800FADS PowerPC.

Узнать, какие флеш-устройства поддерживаются в ОС QNX Neutrino в настоящее время, можно из следующих источников:

каталоги boards и mtd-flash в bsp_working_dir/src/hardware/flash;
документация на ОС QNX Neutrino (см. devf-* в "Руководстве по утилитам" (Utilities Reference));
веб-сайт компании QNX Software Systems (www.qnx.com).

Разработка драйверов

Кроме готовых файловых систем драйверы (в том числе "типовые" драйверы devf-generic) содержат библиотеки и исходный код, необходимые для разработки специализированных файловых систем во флеш-памяти, предназначенных для различных встраиваемых систем. Более подробные сведения можно найти в главе, посвященной специализированной разработке драйверов файловых систем во флеш-памяти, в электронном документе «QNX Neutrino Realtime Operation System. Building Embedded Systems».

Поддержка множества флеш-устройств

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

Каждый сокет может быть разбит на несколько разделов. Поддерживается два типа разделов: разделы с линейным доступом (raw partitions) и разделы с файловой системой (flash filesystem partitions).

Разделы с линейным доступом

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

Посредством точки монтирования для устройств с линейным доступом (raw mountpoint) (см. далее) файловая система обеспечивает доступ ко всем разделам во флеш-памяти, которые не являются разделами с файловой системой. Необходимо отметить, что разделы с файловой системой также могут служить в качестве разделов с линейным доступом.

Разделы с файловой системой

Раздел с файловой системой содержит POSIX-подобную файловую систему во флеш-памяти, которая использует специальный формат QNX для хранения данных файловой системы на флеш-устройстве. Этот формат несовместим со спецификациями Microsoft FFS2 и PCMCIA FTL.

Файловая система FFS3 позволяет свободно создавать и удалять файлы и каталоги, а с помощью специального механизма восстановления (reclaim mechanism) пространство, освободившееся после удаления файлов, вновь становится доступным для использования.

Точки монтирования

При запуске драйвера файловой системы во флеш-памяти он по умолчанию присоединяет все разделы, которые находит в сокете. Тем не менее, можно задать точку монтирования с помощью утилиты mkefs или flashctl (например, /flash) — табл. 9.4.

Таблица 9.4. Точки монтирования

Точка монтирования	Описание
/dev/fsX	Точка монтирования для устройств с линейным доступом, сокет X
/dev/fsXpY	Точка монтирования для устройств с линейным доступом, сокет X, раздел Y
/fsXpY	Точка монтирования для файловой системы, сокет X, раздел Y
/fsXpY/.cmp	Точка монтирования для сжатой файловой системы, сокет X, раздел Y

Возможности

Файловая система FFS3 обладает многими расширенными возможностями и свойствами, в том числе такими, как POSIX-совместимость, многопоточность, фоновое восстановление (background reclaim), восстановление после сбоев, прозрачная распаковка сжатых данных, определение порядка следования байтов (endian-awareness), механизм выравнивания износа, исправление ошибок.

Поддержка спецификации POSIX

Файловая система FFS3 поддерживает стандартные функции, определенные спецификацией POSIX, включая длинные файловые имена, привилегии доступа, запись с произвольным доступом (random writes), укорачивание файлов (truncation), символьные ссылки. Однако есть два исключения:

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

Эти исключения позволяют сделать файловую систему FFS3 компактной и простой, но при этом иметь основные функции, необходимые для работы с блок-ориентированными устройствами хранения.

Фоновое восстановление

Файловая система FFS3 хранит файлы и каталоги в виде связного списка экстентов, которые при удалении или обновлении помечаются соответствующим образом. Блоки, подлежащие восстановлению, выбираются с помощью простого алгоритма, который определяет блок с наибольшим освободившимся пространством с учетом уровня его износа. Механизм выравнивания износа позволяет повысить показатель среднего времени между отказами (MTBF) во флеш-устройствах, таким образом, увеличивая срок их службы.

Процесс фонового восстановления (background reclaim) запускается в том случае, когда не хватает свободного пространства. Для этого сначала копируется содержимое восстанавливаемого блока в пустой блок. Затем это содержимое в восстанавливаемом блоке стирается. В отличие от устройств хранения данных на вращающихся носителях, для флеш-устройств т. н. фактор близости данных (proximity of data) не имеет значения, поэтому данные могут быть как угодно разбросаны в среде хранения — это не влияет на производительность.

Восстановление после сбоев

Файловая система FFS3 способна минимизировать потери данных, происходящие из-за неожиданных сбоев электропитания. Обновления заголовков экстента (extent headers) и заголовков стираемых блоков (erase block headers) всегда выполняются по строго спланированным процедурам. Эти процедуры обеспечивают восстановление целостности файловой системы в случае возникновения сбоя.

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

В файловой системе FFS3 операции переименования всегда атомарны, даже в случаях потери электропитания. Это означает, что если, например, происходит сбой электропитания во время переименования файла с изображением или исполняемым модулем, то после восстановления системы этот файл будет иметь свое прежнее имя.

При запуске драйвера файловой системы FFS3 он определяет состояние каждого заголовка экстента, имеющегося в среде хранения, и при этом выполняет необходимые операции (от простого восстановления блоков (block reclamation) до стирания потерянных цепочек экстентов). Этот процесс входит в обычную процедуру монтирования, выполняемую файловой системой, и позволяет оптимизировать время начальной загрузки.

Сжатие/распаковка файлов

Для быстрого и эффективного сжатия или распаковки данных служит пара утилит deflate/inflator, которые основаны на общеизвестных алгоритмах.

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

Утилита deflate предназначена для работы при использовании утилиты mkefs с атрибутом фильтрации. Эту утилиту также можно использовать с целью предварительного сжатия данных, предназначенных для файловой системы во флеш памяти.

Администратор ресурсов inflator расположен перед сжатыми (с помощью утилиты deflate) файловыми системами и позволяет почти вдвое увеличить полезный объем флеш-памяти.

Сжатые файлы можно обрабатывать с помощью стандартных утилит (например, cp или ftp). При использовании правильной точки монтирования утилита ls позволяет отобразить текущий и фактический размер сжатого файла. В результате работа со сжатыми файловыми системами становится практически прозрачной.

Ошибки во флеш-памяти

По мере износа микросхем флеш-памяти ее конечный автомат записи (write state-machine) может обнаружить, что запись или удаление некоторого бита невозможно. В этом случае драйверу файловой системы во флеш-памяти передается сообщение об ошибке для того, чтобы он применил соответствующее действие (т. е. отметил неисправную область и попытался выполнить операцию записи/стирания в другом месте).

Этот механизм обработки ошибок является прозрачным. Нужно отметить, что после нескольких подобных ошибок все операции записи и удаления, которые дают сбой, приведут к тому, что флеш-память станет доступной только для чтения. Тем не менее, это не должно случиться ранее, чем через несколько лет непрерывной работы. Для того чтобы рассчитать потенциальный срок жизни микросхемы флеш-памяти или ее параметр среднего времени наработки между отказами (MTBF), следует учитывать ее технические характеристики и объем потока данных, который производит система для этой микросхемы флеш-памяти.

Определение порядка следования байтов

Файловая система FFS3 способна определять порядок следования байтов (endian-awareness), что делает ее переносимой между разными платформами. Для выбора порядка следования байтов оптимальной является утилита mkefs.

Утилиты

Файловая система FFS3 поддерживает все стандартные утилиты стандарта POSIX, в том числе ls, mkdir, rm, ln и cp. Кроме того, в ОС QNX Neutrino для управления флеш-памятью предусмотрены и другие утилиты:

flashctl — служит для обнуления, форматирования и монтирования разделов флеш-памяти;
deflate — служит для сжатия файлов, используемых файловыми системами во флеш-памяти;
mkefs — служит для создания файлов, содержащих образ файловой системы во флеш-памяти.

Системные вызовы

Файловая система FFS3 поддерживает все стандартные функции ввода/вывода, предусмотренные в стандарте POSIX, в том числе open(), close(), read() и write(). Такие специальные функции, как, например, обнуление, применяются с помощью функции devctl().

Файловая система NFS

Сетевая файловая система (Network File System, NFS) обеспечивает для клиентских рабочих станций прозрачный доступ к файлам через сеть, при этом она позволяет работать с расположенными на сервере файлами, проходя через множество различных операционных систем. Клиентские вызовы на доступ к файлам преобразуются в вызовы протокола NFS и пересылаются на сервер через сеть. Сервер получает вызов, выполняет запрошенную файловую операцию и отправляет ответ клиенту.

Сетевая файловая система работает без поддержки хранения адресов (stateless) посредством использования удаленных вызовов процедур (Remote Procedure Call, RPC) и протокола TCP/IP, поэтому для того чтобы использовать модули fs-nfs2 и fs-nfs3 необходимо также запустить клиент TCP/IP для Neutrino.

Любые ограничения спецификации POSIX, существующие в файловой системе удаленного сервера, также будут переданы клиенту. Например, длина файловых имен может различаться на серверах в зависимости от операционной системы. Файловая система NFS (версии 2 и 3) ограничивает файловые имена до 255 символов. Утилита mountd (версии 1 и 3) ограничивает файловые имена до 1024 символов.

Замечание

Хотя файловая система NFS (версии 2) существовала до появления стандарта POSIX, она была разработана таким образом, чтобы эмулировать семантику файловой системы UNIX, и поэтому относительно близка к стандарту POSIX.

Поскольку NFS версии 2 старше, чем POSIX (version 2), она была реализована так, чтобы эмулировать семантику файловой системы UNIX. Поэтому иногда она относительно близка к POSIX. Тем не менее, при наличии возможности, вместо fs-nfs2 следует использовать fs-nfs3.

Файловая система CIFS

Файловая система CIFS (Common Internet File System, общая файловая система Интернета), которая ранее называлась SMB (Server Message Block, блок серверных сообщений), позволяет клиентской рабочей станции получать прозрачный сетевой доступ к файлам на SMB-сервере, работающем под управлением ОС Windows 98, NT или UNIX. Клиентские запросы на доступ к файлам преобразуются в вызовы протокола CIFS и пересылаются на сервер через сеть. Сервер получает вызов, выполняет запрошенную файловую операцию и отправляет ответ клиенту.

Замечание

Протокол CIFS не соответствует спецификации POSIX.

Модуль fs-cifs (SMBfsys в ОС QNX 4) использует протокол TCP/IP, поэтому для его работы необходимо также запустить клиент TCP/IP для Neutrino.

Файловая система Ext2 для ОС Linux

Файловая система Ext2 (fs-ext2.so) обеспечивает прозрачный доступ к дисковым разделам Linux. Эта реализация поддерживает стандартный набор возможностей, который имеется в файловой системе Ext2 версии 0 и 1.

В данной файловой системе есть поддержка разреженных файлов (sparse file), которая обеспечивает совместимость с существующими разделами Linux. Другие файловые системы могут быть только каскадированы (stacked) поверх разреженных файлов в режиме "только для чтения". Для обычных файлов эти ограничения отсутствуют.

Если файловая система Ext2 не была монтирована корректно, то при следующем монтировании обычно производится восстановление ее целостности с помощью утилиты проверки файловой системы (filesystem checker). Хотя модуль fs-ext2.so содержит средства для выполнения быстрого теста, он автоматически монтирует файловую систему в режиме "только для чтения", если обнаруживает какие-либо значительные проблемы (которые должны быть исправлены с помощью утилиты проверки файловой системы).

Файловая система UDF

Файловая система UDF (Universal Disk Format) обеспечивает доступ к таким записываемым носителям как CD, CD-R, CD-RW и DVD. Она предназначена для видео DVD, но может использоваться для резервного копирования данных на CD и других задач. Более подробная информация доступна в Интернете по адресу http://osta.org/specs/index.htm.

Файловая система UDF реализуется разделяемым объектом fs-udf.so.

Примечание. В реализации QNX Neutrino файловые системы UDF являются доступными только по чтению.

Файловые системы HFS и HFS Plus

Файловые системы HFS (Hierarchical File System) и HFS Plus используются в системах Apple Macintosh.

Доступ по чтению к файловым системам HFS и HFS Plus в системах QNX Neutrino обеспечивается разделяемым объектом fs-mac.so. Этот ресурс-менеджер способен распознавать следующие варианты: HFS, HFS Plus, HFS Plus в «обертке» HFS, HFSX и гибрид HFS/ISO-9660. Он может также распознавать HFSJ (HFS Plus с журналированием), но только только в том случае, когда журнал «чистый», а не «грязный» вследствие некорректного останова системы.

Файловая система NTFS

Файловая система NTFS используется в системах Microsoft Windows NT и более новых ОС корпорации Microsoft. Доступ по чтению к файловым системам NTFS в системах QNX Neutrino обеспечивается разделяемым объектом fs-nt.so.

Виртуальные файловые системы

QNX Neutrino предоставляет файловую систему Inflator для распаковки данных "на лету", которая представляет собой ресурс-менеджер inflator, регистрирующий свое путевое имя (префикс) перед другими файловыми системами и выполняющим распаковку файлов, ранее сжатых с помощью утилиты deflate.

Утилита inflator обычно используется в тех случаях, когда основной файловой системой является файловая система во флеш-памяти. Эта утилита позволяет почти вдвое увеличить полезный объем флеш-памяти.

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

Таким образом, с точки зрения приложения файл всегда остается несжатым. Утилита inflator поддерживает также произвольное позиционирование (random seeks). Если приложение вызывает функцию stat(), то она вернет размер распакованного файла (т. е. изначальный размер файла, который был до его сжатия).

⁷ CRC (Cyclic Redundancy Check) — контроль циклическим избыточным кодом. — Прим. ред.

⁸ ECC (Error Correction Code) — код коррекции ошибок — тип системной памяти и кеша, который может обнаруживать и устранять некоторые ошибки памяти, не прерывая процесс доступа к памяти. — Прим. ред.

⁹ То есть от 80h до FFh. — Прим. науч. ред.