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

Файловые системы, поддерживаемые в ЗОСРВ «Нейтрино»

Операционная система ЗОСРВ «Нейтрино» предоставляет множество файловых систем, что позволяет без труда работать с дисками, на которых используются файловые системы DOS, Linux и QNX4, а также собственная файловая система ЗОСРВ «Нейтрино».

На настольном компьютере с операционной системой ЗОСРВ «Нейтрино» необходимые блочные файловые системы запускаются при загрузке; другие файловые системы запускаются пользователем как отдельные администраторы. Блочной файловой системой по умолчанию является QNX4.

Настройка, запуск и остановка блочной файловой системы

При загрузке компьютера операционная система обнаруживает разделы на устройствах блочного ввода/вывода и автоматически запускает нужную файловую систему для каждого раздела (см. Управление запуском ЗОСРВ «Нейтрино»).

Скорее всего, пользователю вообще не потребуется останавливать или перезапускать блочную файловую систему. Чтобы обновить файловую систему при изменении ее параметров, можно воспользоваться командой mount с параметром -e или -u.

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

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

Некоторые файловые системы поддерживают возможность маркировать их как «грязные». Это позволяет пропускать интенсивные проверки логической целостности при последующих загрузках. В файловых системах QNX4 и Ext2 для этой цели служит бит, выполняющий функцию флага. В файловых системах FAT для этого предназначены сигнатуры из нескольких бит. Идея заключается в том, что при монтировании файловой системы с правами по чтению и записи выставляется этот флаг, а после корректного отмонтирования файловой системы флаг сбрасывается. Между этими двумя событиями файловая система считается «грязной» и может нуждаться в проверке. Файловая система Power-Safe такого флага не имеет — она просто откатывается к последнему целостному «снимку» ( snapshot). Для отключения данного маркирования используется опция «blk marking=none», подробнее см. описание io-blk.so в справочнике по утилитам.

Монтирование и демонтирование файловых систем

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

Например, если процесс fs-cifs уже работает, то к нему можно смонтировать файловую систему следующим образом:

По умолчанию файловые системы монтируются в режиме доступа по «чтению-записи» (read-write), если это позволяет данный физический носитель. Для монтирования в режиме «только чтение» (read only) используется опция -r утилиты mount. Библиотека io-blk.so так же поддерживает опцию ro для монтирования в режиме «только чтения» блок-ориентированных файловых систем.

Для временного изменения режима монтирования файловой системы используется опция -u утилиты mount. Например, если некоторая файловая система обычно монтируется в режиме «только чтение», но к ней необходимо получить доступ в режиме «чтение-запись», то следует воспользоваться опциями -uw. Например:

Для возврата в режим «только чтение» используются опции -ur:

Перед удалением или извлечением носителя, смонтированного в режиме «чтение-запись» следует предварительно воспользоваться утилитой umount. Более подробные сведения об использовании и синтаксисе утилит mount и umount см. в справочнике по утилитам.

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

В данном контексте под термином образ (image) понимается образ операционной системы – файл, который содержит операционную систему, исполняемые файлы и файлы данных, связанные с программами, и предназначен для использования во встраиваемой системе. Образ можно уподобить небольшой "файловой системе", поскольку он имеет каталоговую структуру, в которой содержатся файлы.

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

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

Пример, который приведен выше, демонстрирует два аспекта функционирования образа операционной системы как файловой системы. При вводе команды ls операционная система загружает утилиту ls (путевое имя /proc/boot/ls) из файловой системы своего образа. Затем при вводе команды cat операционная система загружает утилиту cat также из файловой системы образа и открывает файл data1.

Конфигурирование образа операционной системы

Создать образ операционной системы можно с помощью утилиты mkifs (от англ. MaKe Image FileSystem — сборка файловой системы образа). Более подробные сведения см. в описании утилиты mkifs.

Файловая система в ОЗУ: каталог /dev/shmem

Операционная система «Нейтрино» обеспечивает простую файловую систему в оперативной памяти (ОЗУ), которая позволяет помещать файлы в каталог /dev/shmem для выполнения операций считывания и записи.

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

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

Файлы, которые находятся в каталоге /dev/shmem, помечены как именованные специальные файлы (S_IFNAME). Это обманывает многие утилиты (например, gzip и more), которые работают с обычными файлами (S_IFREG). По этой причине многие утилиты могут не работать с файловой системой в ОЗУ.

При сжатии и разжатии файлов в /dev/shmem с помощью gzip необходимо задавать опцию -f.

Файловая система в оперативной памяти в основном используется подсистемой разделяемой памяти модуля procnto-*. В особых ситуациях (например, при отсутствии файловой системы) файловую систему в ОЗУ можно использовать для хранения файловых данных. Средств, предотвращающих поглощение всей оперативной памяти одним файлом, не существует. Такое поглощение может привести к проблемам в других процессах.

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

Файловая система в оперативной памяти входит в состав модуля procnto-* и не требует настройки и драйверов устройств. Можно просто создавать файлы в каталоге /dev/shmem и увеличивать их до любого размера (в зависимости от ресурсов оперативной памяти).

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

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

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

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

Файловая система QNX4 используется в операционной системе ЗОСРВ «Нейтрино» по умолчанию и имеет ту же дисковую структуру, что и файловая система операционной системы QNX4. Она реализована в виде разделяемого объекта fs-qnx4.so и автоматически загружается драйверами devb-* при монтировании.

Для создания дискового раздела можно воспользоваться утилитами fdisk и dinit.

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

Файловая система QNX4 включает в себя следующие возможности:

В файловой системе QNX4 обычные файлы и каталоги хранятся в виде последовательности экстентов (extents) — непрерывных последовательностей дисковых блоков. Экстенты файла регистрируются в его каталоговом элементе. Если для хранения файла файловой системе требуется более чем один экстент, она использует связанный список блоков экстентов (extent blocks), который содержит информацию об экстентах.

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

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

Исходная файловая система QNX4 поддерживала имена файлов длиной не более 48 символов. Благодаря обратно-совместимому расширению, которое используется по умолчанию, этот предел увеличился до 505 символов. Дисковый формат остался неизменным. Новые системы распознают расширенное имя, однако старые системы используют урезанное имя длиной 48 символов.

При создании файловой системы QNX4 по умолчанию поддерживаются длинные имена файлов. Чтобы отключить длинные имена, следует указать параметр -N в вызове утилиты dinit. Чтобы добавить поддержку длинных имен файлов в существующую файловую систему QNX4, необходимо войти в операционную систему как пользователь root и создать в корневом каталоге файловой системы пустой файл с именем .longfilenames, доступный только для чтения, владельцем которого является пользователь root:

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

Определить максимальную длину имени файла, поддерживаемую файловой системой, можно с помощью утилиты getconf:

где корневой_каталог — корневой каталог файловой системы. В именах файлов нельзя использовать символы 0x00—0x1F, 0x7F и 0xFF. Кроме того, символ / (0x2F) является разделителем путевого имени и не может входить в компонент файловой системы. Можно использовать пробелы, но их необходимо заключать в кавычки в командной строке. В кавычки также требуется заключать все групповые символы, которые поддерживает командный интерпретатор. Более подробные сведения см. Применение кавычек со специальными символами.

Данные файла хранятся отдельно от его имени. На одни и те же данные может ссылаться несколько имен. Каждое имя файла называется ссылкой (link) и указывает на реальные данные файла. На самом деле существуют два вида ссылок — жесткие ссылки (hard links), или просто "ссылки", и символьные ссылки (symbolic links), которые описываются в следующем разделе.

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

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

Рисунок 1. Две ссылки, которые указывают на один файл

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

Существуют две другие ситуации, в которых файл может иметь запись в файле /.inodes:

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

Несмотря на то, что создавать жесткие ссылки на каталоги нельзя, каждый каталог имеет две жестко закодированные встроенные ссылки:

Файловое имя "точка" указывает на текущий каталог, а "две точки" — на предыдущий (или родительский) каталог в иерархии.

Следует иметь в виду, что в отсутствие родительского каталога ссылка "две точки" указывает на текущий каталог. Например, запись "две точки" каталога / указывает на каталог /, поскольку перейти на более высокий путевой уровень невозможно.

Стандарт POSIX не требует, чтобы файловая система включала в себя записи . и ... Например, эти записи отсутствуют в файловых системах флэш-устройств и файловой системе /dev/shmem.

Символьные ссылки Символьная ссылка (symbolic link) представляет собой специальный файл, данные которого обычно содержат путевое имя. Когда имя символьной ссылки используется в запросе ввода/вывода, например, в функции open(), ссылочная часть путевого имени заменяется "данными" ссылки и путь определяется заново.

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

В следующем примере каталоги /net/node1/usr/fred и /net/node2/usr/barney связаны друг с другом, несмотря на то, что они находятся в разных файловых системах и даже на разных узлах (рис. 2). Эту связь нельзя создать с помощью жестких ссылок, но можно посредством символьной ссылки следующим образом:

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

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

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

Надежность файловой системы

Файловая система QNX4 обеспечивает высокую производительность без ущерба для надежности. Это достигается несколькими способами.

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

Иногда возникает необходимость обновления всех перечисленных выше структур. Например, если файл перемещается в каталог, последний экстент которого заполнен, каталог требуется расширить. Для таких ситуаций предусмотрена тщательно продуманная последовательность действий, при которой файловая система не повреждается после перезагрузки в случае катастрофической аварии (например, сбоя электропитания) во время выполнения операции. В худшем случае некоторые выделенные блоки могут оказаться неиспользованными. Их можно освободить с помощью утилиты chkfsys. Более подробные сведения см. Резервное копирование и восстановление данных.

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

Файловая система Power-Safe, поддерживаемая разделяемым объектом fs-qnx6.so, обеспечивает сохранность данных от потери и повреждений при аварийных отключениях электропитания. Многие ее характеристики такие же, как у файловой системы QNX4, например следующие:

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

Для создания файловой системы Power-Safe используется утилита mkqnx6fs. Например:

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

После того, как файловая система отформатирована, ее можно смонтировать утилитой mount. Например:

Подробнее об опциях файловой системы Power-Safe см. описание fs-qnx6.so.

Для проверки логической целостности этой файловой системы (чего обычно не требуется делать) используется chkqnx6fs.

Утилита chkfsys, используемая для проверки целостности файловой системы QNX4, будет выдавать сообщение о том, что файловая система Power-Safe повреждена.

Загрузка

В настоящее время для ЭВМ на базе x86 поддерживается загрузка, которая основана на таблицах разделов и использует BIOS, поддерживающие INT13X (LBA).

Утилита mkqnx6fs создает каталог .boot в корне новой файловой системы. Этот каталог всегда присутствует в файловой системе и всегда имеет вторую inode-запись (сам корневой каталог имеет первую inode-запись). Так же утилита mkqnx6fs устанавливает новый вторичный загрузчик в первые 8 Кбайт данного раздела (и прописывает в него расположение и смещение новой файловой системы).

Во время функционирования fs-qnx6.so защищает этот каталог — в частности он не может быть удален или переименован, не может превысить размер 4096 байт (128 записей). Файлы, помещаемые в каталог .boot, считаются загружаемыми образами, созданными утилитой mkifs. Поэтому для удобства целесообразно, что бы имя файла описывало загружаемый образ (например, kpda2018, 2020_with_diskboot или SafeMode_1CPU).

Данный каталог может содержать до 126 элементов. В нем могут создаваться другие типы объектов (например, каталоги или символьные ссылки), на начальный загрузчик будет их игнорировать. Так же загрузчик игнорирует регулярные файлы, если их размер 0 или больше 2 Гбайт, а так же если их имена содержат более 27 символов.

Файловая система автоматически приостанавливает создание «снимков» когда загрузочный образ открыт по записи. Это позволяет гарантировать то, что начальный загрузчик никогда не будет «видеть» частично записанный образ. Обычно образ создается в каком-либо другом месте и затем копируется в каталог .boot, поэтому файлы образов остаются открытыми в течение короткого интервала времени. Тем не менее эта схема работает так же и в том случае, когда вывод утилиты mkifs направляется прямо в финальный загрузочный файл.

Что бы воспрепятствовать использованию этой особенности для DoS-атак загрузочный каталог по умолчанию имеет такие права доступа: root rwx---—. Эти права можно изменить с помощью chmod и chown, но необходимо помнить, что если вы предоставите какому-либо пользователю доступ в данный каталог, то это позволит ему как добавлять собственные образы, так и удалять имеющиеся образы.

Загрузка с файловой системы Power-Safe рассматривается далее в подразделе «Управление загрузкой ЗОСРВ «Нейтрино».

«Снимки»

«Снимок» (snapshot)- это сохраненное представление стабильного состояния файловой системы Power-Safe. Каждая смонтированная файловая система имеет один стабильный «снимок» и одно рабочее представление, в котором выполняются модификации COW (copy-on-write) в стабильный «снимок».

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

Когда файловая система монтируется заново после сбоя по питанию, она восстанавливает последний стабильный «снимок». «Снимки» выполняются:

Создание «снимков» может быть отключено на глобальном или локальном уровне. В случае отключения новый суперблок записываться не будет, а попытка создания снимка будет завершаться с ошибкой EAGAIN (либо без выставления кода ошибки — в случае использования sync или таймеров). Если в момент отмонтирования (неявного или при сбое по питанию) снимки будут оставаться отключенными, то все ожидающие модификации будут сброшены (потеряны).

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

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

Для отключения снимков на глобальном уровне необходимо сбросить флаг FS_FLAGS_COMMITTING на соответствующей файловой системе. Для этого используется вызов devctl() с командой DCMD_FSYS_FILE_FLAGS:

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

В качестве альтернативы можно воспользоваться утилитой chattr (как интерфейсом к указанному выше вызову devctl):

Для отключения снимков на локальном уровне необходимо с помощью той же команды DCMD_FSYS_FILE_FLAGS функции devctl() скорректировать счетчик QNX6FS_SNAPSHOT_HOLD для файлового дескриптора. Каждый открытый файл имеет свой счетчик удержаний, а сумма всех счетчиков удержаний является глобальным счетчиком удержания, отключающим снимки в случае, если его значение ненулевое. Следовательно, если какой-либо клиент устанавливает счетчик удержаний, то снимки отключаются до тех пор, пока все клиенты не сбросят свои счетчики.

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

Достоинство этой схемы заключается в том, что она не требует специальной координации между клиентами; каждый из них может создавать собственные атомарные последовательности операций используя свой независимы счетчик удержаний:

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

Если +snapshot не отображается, то снимки были отключены с помощью глобального флага. Если отображается +hold, то снимки были отключены из-за ненулевого значения глобального счетчика удержаний (установленного неспецифицированным количеством клиентов). Если постоянно (даже после sync()) отображается +dirty, то снимки отключены или из-за возможно фатальной ошибки, или дисковая аппаратура не поддерживает полной синхронизации данных («track cache flush»).

Само по себе включение снимков не приводит к созданию снимка — для этого нужно явно вызвать fsync(). Целесообразно вызывать fsync() как перед выключением, так и после включения снимков (утилита chattr делает этот вызов самостоятельно).

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

Файловая система операционной системы DOS обеспечивает прозрачный доступ к DOS-дискам, что позволяет работать с файловыми системами DOS так же, как и с файловыми системами ЗОСРВ «Нейтрино» (POSIX). Эта прозрачность дает процессам возможность оперировать DOS-файлами без какой-либо специальной информации и дополнительных действий.

Разделяемый объект fs-dos.so позволяет монтировать файловые системы DOS (FAT12, FAT16 и FAT32) в операционной системе ЗОСРВ «Нейтрино». Этот разделяемый объект автоматически загружается драйверами devb-* при монтировании файловой системы FAT операционной системы DOS. Если требуется выполнять операции чтения и записи над гибким диском DOS, его следует смонтировать с помощью команды

Сведения о символах, которые можно использовать в файловых именах в файловой системе DOS см. на сайте сети разработчиков Microsoft (Microsoft Developer Network) http://msdn.microsoft.com. Самые жесткие ограничения налагаются на имена файлов в формате FAT 8.3. В них можно использовать только буквы в верхнем регистре, цифры, а также символы $ % ' — _ @ { } ˜ # ( ). Формат VFAT несколько смягчает эти ограничения и позволяет использовать буквы в нижнем регистре и символы [ ] ; , = +. Файловая система DOS операционной системы ЗОСРВ «Нейтрино» автоматически переводит файловые имена в формате FAT 8.3 в верхний регистр, чтобы сымитировать возможность использования букв в нижнем регистре (информация о регистре, тем не менее, не сохраняется).

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

Файловая система для устройств CD-ROM в операционной системе ЗОСРВ «Нейтрино» обеспечивает прозрачный доступ к компакт-дискам, что позволяет работать с их файловыми системами так же, как с файловыми системами стандарта POSIX. Эта прозрачность дает процессам возможность манипулировать файлами компакт-дисков без какой-либо специальной информации и дополнительных действий.

Разделяемый объект fs-cd.so обеспечивает поддержку файловой системы стандарта ISO 9660, а также различных расширений, в том числе Rock Ridge (RRIP), Joliet (компании Microsoft) и многосеансовых дисков (стандарта Kodak Photo CD, расширенных аудиодисков). Этот разделяемый объект автоматически загружается драйверами devb-* при монтировании файловой системы ISO 9660.

Файловая система для устройств CD-ROM принимает любые символы, которые присутствуют в имени файла. Она допускает только чтение, поэтому все надлежащие ограничения на имя файла должны налагаться программой, которая подготавливает образ компакт-диска. Для строгого соответствия стандарту ISO 9660 необходимо использовать только символы 0, 1, ..., 9, A, ..., Z и _, однако расширения Joliet и Rock Ridge значительно менее требовательны. Сведения о записи компакт-дисков см. в Резервное копирование и восстановление данных.

Модуль fs-cd.so является устаревшим и более не развивается. Для его замены предназначен модуль fs-udf.so, который поддерживает файловые системы ISO-9660 в дополнение к UDF. Информация о UDF представлена ниже, в соответствующем подразделе этого раздела.

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

Файловая система Ext2, которая входит в состав операционной системы ЗОСРВ «Нейтрино», обеспечивает прозрачный доступ к дисковым разделам операционной системы Linux. Эта файловая система не поддерживает некоторые возможности Ext2, в том числе:

Поддержка файловой системы Ext2 обеспечивается разделяемым объектом fs-ext2.so. Этот разделяемый объект автоматически загружается драйверами devb-* при монтировании файловой системы Ext2.

Несмотря на то, что Ext2 является основной файловой системой для операционной системы Linux, не рекомендуется использовать файл fs-ext2.so в качестве замены файловой системы QNX4. В настоящее время загрузка с разделов Ext2 не поддерживается. Кроме того, целостность файловой системы Ext2 в значительной степени обеспечивается специальной проверочной программой. Эта программа и другие утилиты поддержки (например, mke2fs) в настоящее время не реализованы в ЗОСРВ «Нейтрино».

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

Файловая система Ext2 разрешает использовать в имени файла те же символы, что и файловая система QNX4 (см. подраздел "Имена файлов" ранее в этой статье).

Файловые системы флэш-памяти

Операционная система ЗОСРВ «Нейтрино» включает в себя POSIX-совместимые драйверы файловых систем для устройств флэш-памяти типа NOR. Эти драйверы являются самостоятельными исполняемыми файлами, которые содержат код как файловой системы, так и флэш-устройства. Существуют версии драйвера файловой системы флэш-памяти для встраиваемых систем с различным оборудованием, а также для карт памяти стандарта PCMCIA.

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

По соглашению об именах драйвер имеет название вида devf-система, где элемент система описывает встраиваемую систему. Например, драйвер devf-800fads предназначен для демонстрационной платы 800FADS PowerPC. Более подробные сведения об этих драйверах см. в описаниях драйверов devf-*.

Сведения о работе операционной системы ЗОСРВ «Нейтрино» с файловыми системами флэш-памяти см. в следующих источниках:

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

Протокол CIFS (Common Internet File System, общая файловая система Интернета) обеспечивает клиентской рабочей станции прозрачный сетевой доступ к Windows- и UNIX-системам с SMB-сервером. Этот протокол раньше назывался SMB (Server Message Block, блок серверных сообщений) и предназначен для контролируемого доступа к ресурсам локальной сети. Запросы доступа к файлам, которые посылает клиент, преобразуются в запросы протокола CIFS и передаются на сервер по сети. Сервер получает запрос, выполняет фактическую операцию над файловой системой и посылает ответ клиенту. Протокол CIFS функционирует на основе стека протоколов TCP/IP и использует протокол DNS.

Администратор файловой системы fs-cifs является клиентом протокола CIFS и работает по протоколу TCP/IP. Чтобы воспользоваться этим администратором, необходимо наличие SMB-сервера и действительного регистрационного имени на нем. Утилита fs-cifs предназначена в основном для использования в качестве клиента для связи с компьютерами с операционной системой Windows, хотя она работает с любыми SMB-серверами, например OS/2 Peer, LAN Manager и SAMBA.

Администратору файловой системы fs-cifs необходим транспортный уровень TCP/IP. Этот уровень предоставляется администратором сетевого ввода/вывода io-pkt-*.

Дополнительные сведения о паролях и несколько связанных с ними примеров см. в разделе fs-cifs в справочнике по утилитам.

Если необходимо запускать файловую систему CIFS при загрузке компьютера, следует добавить соответствующую команду в файл /etc/host_cfg/$HOSTNAME/rc.d/rc.local или /etc/rc.d/rc.local. Более подробную информацию см. в описании файла /etc/rc.d/rc.sysinit в Управление запуском ЗОСРВ «Нейтрино».

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

Протокол NFS (Network File System, сетевая файловая система) представляет собой TCP/IP-приложение, которое поддерживает сетевые файловые системы. Оно обеспечивает прозрачный межсетевой доступ к разделяемым файловым системам.

Протокол NFS позволяет клиентской рабочей станции работать с файлами, которые расположены на серверах с различными NFS-совместимыми операционными системами. Клиентские вызовы доступа к файлам преобразуются в запросы протокола NFS (см. спецификации RFC 1094 и RFC 1813) и передаются на сервер по сети. Сервер получает запрос, выполняет фактическую операцию над файлом и отсылает ответ клиенту.

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

Файловая система NFS допускает использование в имени файла тех же символов, что и файловая система QNX4 (см. подраздел "Имена файлов" ранее в этой статье).

Настройка NFS

Процедуры, которые используются в операционной системе ЗОСРВ «Нейтрино» для настройки клиентов и серверов, могут отличаться от аналогичных процедур в других операционных системах. Для настройки клиентов и серверов в операционной системе, отличной от ЗОСРВ «Нейтрино», следует обратиться к документации ее поставщика, а также изучить сценарии инициализации, чтобы определить, как в этой системе запускаются программы.

Фактически работа по преобразованию обобщенных методов доступа к файлам, которые предоставляют серверы, в методы доступа к файлам, которые полезны приложениям и пользователям, выполняется клиентами протокола NFS. Чтобы запускать файловую систему NFS при загрузке компьютера, следует поместить соответствующую команду в файл /etc/host_cfg/$HOSTNAME/rc.d/rc.local или /etc/rc.d/rc.local. Более подробную информацию см. в описании файла /etc/rc.d/rc.sysinit Управление запуском ЗОСРВ «Нейтрино».

NFS-сервер

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

Имя	Назначение
rpcbind	Сервер протокола RPC (Remote Procedure Call, удаленный вызов процедур)
nfsd	Сервер NFS и сервис mountd

Сервер rpcbind сопоставляет номера портов протоколов TCP и UDP номерам и версиям программ RPC. Клиенты могут выполнять RPC-вызовы только в том случае, если на сервере работает утилита rpcbind.

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

Сервис nfsd обслуживает запросы монтирования файловой системы NFS и запросы, которые адресованы самой файловой системе NFS, в соответствии с файлом exports. При загрузке программа nfsd считывает файл /etc/exports.имя_хоста или при его отсутствии файл /etc/exports, чтобы определить, какие точки монтирования требуют обслуживания. Изменения, которые вносятся в этот файл, начинают действовать только после перезапуска сервиса nfsd.

NFS-клиент

NFS-клиент запрашивает включение файловой системы, которую экспортирует NFS-сервер, в свое локальное пространство имен. Для того чтобы клиент работал, необходимо сначала запустить вторую или третью версию администратора файловой системы NFS ( fs-nfs2 или fs-nfs3). Во второй версии описатель файла представляет собой 32-байтовый массив фиксированного размера, а в третьей версии — 64-байтовый массив переменной длины.

Администраторы файловой системы fs-nfs2 и fs-nfs3 также являются клиентскими сервисами протоколов NFS2 и NFS3 и работают по протоколу TCP/IP. Для использования этих администраторов необходим NFS-сервер и функционирующий транспортный уровень стека протоколов TCP/IP, например, тот, который обеспечивает администратор сетевого ввода/вывода io-net с модулем npm-ttcpip.so. Кроме того, администраторам fs-nfs2 и fs-nfs3 требуются библиотеки libsocket.so и libc.so.

Создавать точки монтирования NFS можно с помощью команды mount, указывая nfs в качестве типа файловой системы и -o ver3 в качестве параметра. Чтобы создавать точки монтирования таким способом, необходимо предварительно запустить утилиту fs-nfs2 или fs-nfs3. Если администратор fs-nfs2 или fs-nfs3 запускается без аргументов, он работает в фоновом режиме и позволяет использовать команду mount.

Для подачи запроса клиент применяет утилиту mount так, как показано в следующих примерах:

В первом примере клиент запрашивает монтирование каталога /home, который находится на хосте с заданным IP-адресом, в локальное пространство имен как каталог /mnt/home. Во втором примере протокол NFS версии 3 используется для сетевой файловой системы.

Следующая командная строка запускает и монтирует клиента:

Несмотря на то, что файловая система NFS 2 появилась раньше стандарта POSIX, она была создана для имитации семантики файловой системы UNIX и относительно схожа со стандартом POSIX.

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

Файловая система UDF (Universal Disk Format) обеспечивает доступ к таким записываемым носителям как CD, CD-R, CD-RW и DVD. Она предназначена для видео DVD, но может использоваться для резервного копирования данных на CD и других задач.

Файловая система UDF реализуется разделяемым объектом fs-udf.so. Драйверы devb-* автоматически загружают fs-udf.so при монтировании файловой системы UDF.

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

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

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

Драйверы devb-* автоматически загружают fs-mac.so при монтировании файловой системы HFS и HFS Plus.

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

Файловая система NTFS используется в системах Microsoft Windows. Доступ к ней осуществляется только в режиме чтения посредством модуля fs-nt.so.

Драйверы devb-* автоматически загружают fs-nt.so при монтировании файловой системы NTFS. Если необходимо, что бы модуль fs-nt.so эмулировал элементы каталогов . и .., необходимо задать ему опцию dots=on. По умолчанию данные элементы не эмулируются.

Файловая система с распаковкой сжатых данных "на лету"

Операционная система ЗОСРВ «Нейтрино» обеспечивает виртуальную файловую систему с распаковкой сжатых данных "на лету" ( inflator). Она представляет собой администратор ресурсов, который находится перед другими файловыми системами и распаковывает файлы, ранее сжатые с помощью утилиты deflate.

Обычно утилита inflator используется в случае, если базовой файловой системой является файловая система флэш-памяти. С помощью программы inflator можно увеличить эффективный объем флэш-памяти почти в 2 раза.

Устранение неполадок

Далее рассмотрены некоторые проблемы, которые могут возникать при работе с файловыми системами.

`Работа с файловыми системами`

Общие сведения