Рисунок 1. Архитектура драйверов файловых систем
Применение файловых систем следующих типов: Image, RAM, Power-Safe, QNX4, DOS, CD-ROM, Flash, NFS, CIFS, Ext2
В ЗОСРВ «Нейтрино» большинство файловых систем представляют собой менеджеры ресурсов. Каждая файловая система получает свою область в пространстве имен (называемую точкой монтирования) и предоставляет свои службы посредством стандартного программного интерфейса POSIX ( open(), close(), read(), write(), lseek() и т.д.). Менеджер ресурсов файловой системы получают точку монтирования и управляют структурой каталогов ниже этой точки. Они также проверяют отдельные компоненты путевых имен на уровень разрешений и доступа.
Такая схема реализации имеет следующие преимущества:
Любую службу или файловую систему, которая зарегистрирована менеджером процессов, можно бесшовным образом локализовать и присоединить. Когда менеджер ресурсов файловой системы регистрирует точку монтирования, менеджер процессов в ядре создает для нее запись во внутренней таблице монтирования с указанием идентификатора соответствующего сервера (т.е. в записи указываются идентификаторы nd, pid, chid).
Эта таблица в действительности объединяет несколько каталогов файловой системы так, что пользователь воспринимает их как один каталог. Менеджер процессов обрабатывает ту часть путевого имени, которая соответствует точке монтирования, а менеджеры ресурсов файловых систем обрабатывают оставшиеся части имени пути. Файловые системы могут регистрироваться (т.е. монтироваться) в любом порядке.
После разрешения путевого имени менеджер процессов обращается ко всем менеджерам ресурсов файловых систем, которые могут обработать какой-либо компонент этого пути. В результате получается набор файловых дескрипторов, которые могут разрешить данное имя пути.
Если путевое имя означает каталог, менеджер процессов запрашивает список файлов в этом каталоге у всех файловых систем, которые могут разрешить данное имя пути по вызову функции readdir(). Если имя пути не является каталогом, тогда обращение делается к первой файловой системе, которая смогла выполнить разрешение этого имени.
Более подробные сведения о разрешении путевых имен можно найти в разделе Управление пространством имен.
Файловые системы можно разделить на несколько классов:
Так как в ЗОСРВ «Нейтрино» часто используется несколько файловых систем одновременно, их разработали в виде семейства драйверов и разделяемых библиотек для того, чтобы расширить возможности их повторного использования. В результате добавление новых файловых систем, как правило, требует меньше затрат, чем можно было бы ожидать.
Если одна файловая система уже запущена, то расходы ресурсов памяти для добавленной файловой системы будут минимальными, так как для этого понадобится только код для реализации протокола новой файловой системы. Разделяемая библиотека, отвечающая за файловую систему, реализует протокол файловой системы, т.е. логическую организацию набора блоков на физическом устройстве хранения. Файловые системы не встроены в ядро ОС. Скорее, они представляют собой динамические сущности, которые можно по требованию загружать или выгружать.
Как видно из рисунка, файловые системы, драйверы дисков и модуль io-blk реализуются в виде разделяемых библиотек, которые, по сути, представляют собой пассивные блоки программного кода, находящиеся резидентно в памяти, в то время как модуль io-cam является активным исполняемым модулем, который обращается к этим библиотекам. Процесс io-cam запускается первым и вызывает разделяемую библиотеку блочного уровня ( io-blk - block-level shared library) и разделяемые библиотеки дисковых драйверов ( devb-*). Позже могут быть динамически загружены разделяемые библиотеки, реализующие файловую систему, чтобы обеспечить соответствующий интерфейс и службы файловых систем.
Работа большинства разделяемых библиотек файловых систем основана на модуле блочного ввода/вывода ( io-blk). Этот модуль также действует в качестве менеджера ресурсов и объявляет блок-ориентированный файл (block-special file) для каждого физического устройства. В системе с двумя жесткими дисками по умолчанию будут использоваться следующие файлы:
Эти файлы отображают каждый диск с линейным доступом и к ним можно обращаться с помощью всех стандартных POSIX-примитивов для работы с файлами ( open(), close(), read(), write(), lseek() и т.д.). Хотя модуль io-blk поддерживает 64-битное смещение для операций позиционирования, интерфейс драйвера является 32-битным, что позволяет работать с 2-терабайтными дисками.
Модуль io-blk поддерживает работу с внутренними RAM-дисками, которые можно создать посредством задания специальной опции командной строки (blk ramdisk=size). Поскольку RAM-диск создается не дополнительным драйвером устройства (например, devb-ram), а является внутренним по отношению к модулю, его производительность значительно выше, чем у специального драйвера RAM-дисков.
Поскольку RAM-диск реализуется на уровне модуля io-blk, память данных этого устройства работает синхронно с основным кешем, в результате чего операции ввода/вывода могут выполняться без помощи буферного кеша, что избавляет от необходимости копировать память и в то же время сохраняет когерентность кеша (coherency). При сравнении этого подход с другим, а именно с реализацией на уровне драйвера (например, devb-ram), при которой прозрачное отображение памяти в виде блочного устройства требует копирования и дублирования данных посредством буферного кеша. Межбиблиотечные вызовы (inter-DLL callouts) также исключаются. Кроме того, этот метод дает преимущество с точки зрения занимаемого объема ОЗУ для систем, в которых кроме жесткого диска еще требуется псевдодиск, — в этом случае может использоваться один общий драйвер.
ЗОСРВ «Нейтрино» поддерживает общепринятый промышленный стандарт разбиения дисков на разделы. Такое разбиение позволяет использовать несколько файловых систем на одном физическом диске. Каждый раздел представляется в виде блок-ориентированного файла, а тип раздела добавляется к файловому имени диска, на котором он находится. В приведенном ранее примере с двумя дисками, если первый диск имеет раздел QNX4 и раздел DOS, а второй диск имеет только раздел QNX4, то по умолчанию диски будут содержать следующие файлы:
В таблице ниже приведены некоторые часто используемые типы разделов.
| Тип | Файловая система |
|---|---|
| 1 | DOS (FAT12) |
| 4 | DOS (FAT16, разделы не более 32 Мбайт) |
| 5 | Расширенный раздел DOS |
| 6 | DOS 4.0 (FAT16, разделы от 32 Мбайт) |
| 7 | OS/2 HPFS1 |
| 7 | Предыдущая версия QNX2 (до 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 | Раздел QNX4 POSIX (вторичный) |
| 79 | Раздел QNX4 POSIX (вторичный) |
| 77 | Раздел QNX4 POSIX |
| 99 | UNIX |
| 131 | Linux (Ext2) |
| 175 | Apple Macintosh HFS или HFS Plus |
| 177 | Power-Safe POSIX partition (вторичный) |
| 178 | Power-Safe POSIX partition (вторичный) |
| 179 | Power-Safe POSIX partition |
Разделяемая библиотека io-blk реализует буферный кеш (buffer cache), который наследуется всеми файловыми системами. Буферный кеш предназначен для сохранения часто используемых блоков файловой системы для того, чтобы уменьшить число выполняемых файловой системой физических операций дискового ввода/вывода.
Операции чтения являются синхронными, тогда как операции записи, как правило, асинхронны. Когда приложение выполняет запись в файл, данные поступают в кеш, а менеджер файловой системы сразу же посылает клиентскому процессу ответное сообщение о том, что данные были записаны. После этого данные записываются на диск.
Критические блоки файловой системы (блоки битовой карты, каталоговые блоки, блоки экстентов и блоки индексных дескрипторов) записываются на диск немедленно и синхронно.
Приложения могут изменять порядок выполнения операций записи для каждого файла. Например, база данных может установить синхронное выполнение всех операций записи для заданного файла. Это обеспечит высокий уровень целостности данного файла и позволит избежать потенциальных проблем с оборудованием или электропитанием, которые могут привести к противоречивым состояниям базы данных.
Стандарт POSIX определяет набор служб, которые должны предоставлять файловые системы. Однако, не все файловые системы могут их поддерживают:
| Файловая система | Время доступа | Время изменения | Время изменения статуса | Длина имени файла¹ | Права доступа | Каталоги | Жесткие ссылки | Символьные ссылки | Декомпрессия при чтении |
|---|---|---|---|---|---|---|---|---|---|
| Загрузочного образа | Нет | Нет | Нет | 255 | Да | Нет | Нет | Нет | Нет |
| RAM | Да | Да | Да | 255 | Да | Нет | Нет | Нет | Нет |
| ETFS | Да | Да | Да | 91 | Да | Да | Нет | Да | Нет |
| QNX4 | Да | Да | Да | 48² | Да | Да | Да | Да | Нет |
| Power-Safe | Да | Да | Да | 510 | Да | Да | Да | Да | Нет |
| DOS | Да³ | Да | Нет | 8.3⁴ | Нет | Да | Нет | Нет | Нет |
| NTFS | Да | Да | Нет | 255 | Нет | Да | Нет | Нет | Да |
| CD-ROM | Да⁵ | Да⁵ | Да⁵ | 207⁶ | Да⁵ | Да | Нет | Да⁵ | Нет |
| UDF | Да | Да | Да | 254 | Да | Да | Нет | Нет | Нет |
| HFS | Да | Да | Да | 255⁷ | Да | Да | Нет | Нет | Нет |
| FFS3 | Нет | Да | Да | 255 | Да | Да | Нет | Да | Да |
| NFS | Да | Да | Да | –⁸ | Да⁸ | Да | Да⁸ | Да⁸ | Нет |
| CIFS | Нет | Да | Нет | –⁸ | Да⁸ | Да | Нет | Нет | Нет |
| Ext2 | Да | Да | Да | 255 | Да | Да | Да | Да | Нет |
.longfilenames; в противном случае, 48.
Каждый образ в ЗОСРВ «Нейтрино» представляет собой простую файловую систему, предназначенную только для чтения, которая отображает набор файлов, встроенных в образ ОС.
Поскольку образ может включать в себя как исполняемые модули, так и файлы с данными, эта файловая система имеет достаточный набор возможностей, который подходит для многих встраиваемых систем. Если требуются дополнительные файловые системы, их можно разместить в виде модулей внутри образа и запускать по мере необходимости.
В каждой системе есть простая "файловая система" в ОЗУ (RAM filesystem), которая позволяет размещать файлы чтения/записи в каталог /dev/shmem.
 | Обратите внимание, что /dev/shmem в действительности не является файловой системой. Это обладающее некоторыми характеристиками, похожими на файловую систему, окно к именам объектов разделяемой памяти. |
Файловая система в ОЗУ находит наибольшее применение в миниатюрных встраиваемых системах, для которых не требуются постоянные запоминающие устройства, чтобы выполнять перезагрузку, но необходима компактная, быстродействующая файловая система с минимальными функциональными возможностями на основе временного запоминающего устройства.
Такая файловая система входит в состав модуля procnto и не требует какой-либо настройки. С ее помощью можно создавать файлы в каталоге /dev/shmem и увеличивать их до любого размера в зависимости от ресурсов ОЗУ.
Хотя файловая система в ОЗУ не поддерживает ни жестких, или символьных, связей, ни каталогов, можно создать ссылку на нее с помощью механизма ссылок, предоставляемого менеджером процессов. Например, можно создать связь с каталогом /tmp, находящимся в ОЗУ:
ln -sP /dev/shmem /tmp
Эта команда указывает модулю procnto связать менеджер процессов с каталогом /dev/shmem, который обозначен как /tmp. В результате приложения могут открывать файлы в каталоге /tmp, как будто это обычная файловая система.
| Для того чтобы минимизировать объем кода файловой системы в ОЗУ, реализованного внутри менеджера процессов, из этой файловой системы были исключены такие присущие обычным файловым системам функции, как блокировка файлов и создание каталогов. |
Встраиваемая транзакционная файловая система (Embedded transaction filesystem, ETFS) является высоконадежной файловой системой, предназначенной для устройств с полупроводниковой памятью, и в частности флеш-памяти типа NAND. Эта файловая система поддерживает полностью иерархическую структуру каталогов с POSIX-семантикой.
Файловая система ETFS целиком основана на механизме транзакций (transactions). Каждая операция записи (пользовательских данных или метаданных файловой системы) состоит из выполнения транзакции. Транзакция может быть успешно выполнена только целиком. В противном случае считается, что она вообще не выполнялась.
При выполнении транзакций никогда не производится перезапись обновляемых (live) данных. Если запись происходит во время обновления файла или каталога, то она всегда выполняется в другой, свободной области. Таким образом, если в момент выполнения операции случается какой-либо сбой (например, из-за отказа системы или потери электропитания), старые данные остаются в сохранности.
Принцип запрета на перезапись обновляемых данных также используется в некоторых журналируемых файловых системах. Однако в файловой системе ETFS этот принцип реализуется радикальным образом, так как в журнал транзакций заносятся абсолютно все операции. Иерархическая структура файловой системы выстраивается "на лету" посредством обработки журнала транзакций, связанного с соответствующим устройством. Сканирование файловой системы производится при запуске, но при этом только небольшая часть данных используется для чтения и CRC-проверки, что ускоряет загрузку, не снижая надежности.
Транзакции не зависят от позиции смещения и могут выполняться в любом порядке. Можно прочитать транзакции на одном устройстве и записать их на другое устройство в другом порядке. Эта ценная возможность позволяет выполнять однопроходное (bulk) программирование устройств, в которых есть дефектные блоки.
Это хорошо подходит для флеш-памяти NAND, так как в ней бывают дефектные блоки, которые специальным образом помечаются производителем и могут встречаться в любой области.
Каждая транзакция состоит из заголовка и последующего блока данных. В заголовке содержится следующая информация:
Хотя файловая система ETFS лучше всего подходит для устройств хранения данных типа NAND, она поддерживает также и другие типы встраиваемых сред хранения с помощью следующих классов драйверов:
| Класс | CRC | ECC | Стирание по степени износа (wear-leveling) | Чтение по степени износа (wear-leveling) | Размер кластера |
|---|---|---|---|---|---|
| NAND 512 + 16 | Да | Да | Да | Да | 1 Кб |
| NAND 2048 + 64 | Да | Да | Да | Да | 2 Кб |
| RAM | Нет | Нет | Нет | Нет | 1 Кб |
| SRAM | Да | Нет | Нет | Нет | 1 Кб |
| NOR | Да | Нет | Да | Нет | 1 Кб |
| Хотя файловая система ETFS может поддерживать флеш-память типа NOR, рекомендуется применять файловую систему FFS3 ( devf-*), которая разработана специально для этого типа флеш-памяти. |
Файловая система ETFS способна сохранять свою работоспособность после сбоев электропитания даже в случаях, когда такой сбой происходит в момент выполнения операции записи или удаления блока данных. Отказоустойчивость файловой системы обеспечивается следующими функциями:
Каждый блок флеш-памяти допускает ограниченное количество безотказных циклов стирания, которое не превышает 100 000. Файловая система ETFS ведет подсчет количества стираний по каждому блоку памяти для того, чтобы учитывать их износ при выборе блоков памяти для использования и попытаться равномерно распределить нагрузку между ними. Это позволяет значительно увеличить срок службы устройства. Разница может быть весьма ощутимой: без выравнивания износа сбой может произойти в течение нескольких дней, а при его использовании может быть обеспечена безотказная работа в течение более чем 40 лет.
Файловые системы часто состоят из большого числа статичных файлов, которые используются только для чтения, т.е. эти файлы занимают блоки флеш-памяти, которые не должны стираться. Если большинство файлов в файловой системе являются статичными, то остальные блоки флеш-памяти, в которых хранятся изменяющиеся данные, будут изнашиваться значительно быстрее.
Файловая система ETFS отслеживает статичные блоки с низким износом и перемещает данные из них в блоки с повышенным износом. Это позволяет решить две проблемы: во-первых, интенсивно используемые блоки флеш-памяти получают отдых, поскольку теперь содержат статичные данные, а во-вторых, статичные блоки флеш-памяти, которые используются менее интенсивно, получают большую нагрузку.
Каждая транзакция защищена кодом CRC, который позволяет быстро выявить данные с ошибкой, и служит основой для выполнения отката ошибочной или незавершенной транзакции при старте. CRC-код помогает выявить множество ошибок в разрядах, которые случаются при сбое электропитания.
При обнаружении ошибки по CRC-коду файловая система ETFS может применить код исправления ошибки (ECC-код) для восстановления данных. Исправление ошибок по ECC-коду используется для флеш-памяти типа NAND, в которой могут случаться ошибки в одном разряде. Возникновение ECC-кода является сигналом, предупреждающим о том, что блок флеш-памяти, в котором произошла ошибка, возможно, начинает "уставать" (weak), т.е. теряет свой заряд.
Файловая система ETFS отмечает усталый блок для операции обновления, в результате которой данные копируются в другой блок флеш-памяти, а содержание усталого блока стирается, т.е. производится его перезарядка.
Каждая операция чтения внутри блока флеш-памяти типа NAND приводит к ослаблению заряда, с помощью которого хранятся данные. Большинство устройств обеспечивают до 100 000 гарантированных операций чтения. ECC-код позволяет исправлять ошибки в одном бите, но при ошибках во множестве битов этот код может оказаться бесполезным.
В файловой системе ETFS эта проблема решается следующим образом: файловая система отслеживает операции чтения и периодически обновляет блоки памяти до того, как количество операций превысит установленный предел 100 000.
При запуске файловой системы ETFS она обрабатывает все транзакции и откатывает (отменяет) последние частично выполненные или не успешные транзакции. Программный код, который реализует операцию отката, разработан таким образом, что даже при сбое электропитания, произошедшем в момент операции отката, попытка ее выполнения будет предпринята вновь после перезагрузки, что позволяет системе восстанавливаться даже после множественных последовательных сбоев. Необходимость выполнения транзакции в каждом случае проверяется по CRC-коду.
Файловая система ETFS реализует очень простую структуру каталогов, которая позволяет выполнять значительные изменения по одной операции записи. Например, перемещение файла или каталога в другой каталог в большинстве файловых систем представляет собой многоэтапную операцию. В файловой системе ETFS такое перемещение осуществляется посредством единственной операции записи.
В журналируемых файловых системах часто наблюдается такой недостаток, как фрагментированность, поскольку каждое обновление или запись данных в существующий файл связано с созданием новой транзакции. В файловой системе ETFS для объединения нескольких небольших операций записи в одну большую транзакцию применяется буферизация операций для уменьшения фрагментации, которая возникает при выполнении множества небольших транзакций. Кроме того, файловая система ETFS следит за уровнем фрагментированности каждого файла и, если этот уровень для какого-то файла становится слишком высоким, выполняет дефрагментацию файла в фоновом режиме. Однако фоновая дефрагментация всегда вытесняется при запросе данных из этого файла для обеспечения немедленного доступа к ним.
Файловая система QNX4 ( fs-qnx4.so) имеет высокую отказоустойчивость благодаря использованию экстент-ориентированной схемы распределения блоков на основе битовой карты, а также применению специализированных подписей, которые обеспечивают защиту от потерь данных и возможность быстрого восстановления. Эта экстент-ориентированная файловая система обладает следующими особенностями:
Более подробные сведения об этой файловой системе можно найти в разделе Работа с файловыми системами.
Файловая система Power-Safe, известная так же как файловая система QNX6, поддерживается менеджером fs-qnx6.so, реализованным в виде разделяемого объекта. Это надежная дисковая файловая система, которая выдерживает сбои по питанию без потерь или повреждений данных. Она разработана для традиционных вращающихся жестких дисковых накопителей.
Подробную информацию об использовании данной файловой системы см. в разделе Файловая система Power-Safe.
Несмотря на то, что дисковые файловые системы разработаны для обеспечения надежности и отказоустойчивости, они, тем не менее, могут терять данные в случае катастрофического отказа (например, при отключении питания):
Существуют диски с атомарной записью секторов, производители которых утверждают, что в любом случае либо старые, либо новые данные будут доступны для чтения. Однако такие устройства встречаются редко и соответствующим образом стоят.
Для решения проблем, связанных с существующими файловыми системами, файловая система Power-Safe никогда не перезаписывает актуальные данные; все обновления выполняются методом COW (copy-on-write, копирование-при-записи), формирующим новое представление файловой системы на неиспользованных блоках диска. Новое представление файловой системы становится рабочим только, когда все обновления записаны на диск и целостны. В файловой системе, реализующей COW защищены как метаданные, так и данные пользователя.
Чтобы увидеть, как это действует, необходимо рассмотреть сохранение данных. Файловая система Power-Safe разделена на логические блоки, размер которых можно задавать при использовании mkqnx6fs для форматирования файловой системы. Каждый индексный дескриптор содержит 16 указателей блока. Если файл меньше, чем 16 блоков, индексный дескриптор указывает прямо на данные блока. Если файл слишком большой, эти 16 блоков становятся указателями к другим блокам и т.д.
Все конечные (финальные) блочные указатели на реальные данные расположены в листьях и имеют один и тот же уровень. В некоторых других системах – таких как EXT2 – файл содержит несколько прямых блоков, несколько непрямых, и несколько двойных непрямых, т.о. Перемещение по уровням действует как перемещение по разным частям файла. В файловой системе Power-Safe все данные пользователя в файле находятся на одном уровне.
При изменении каких-либо данных, они будут записаны в один или несколько неиспользуемых блоков, а исходные данные останутся неизменными. Список непрямых блоковых указателей может быть изменен обращением к недавно используемым блокам, но файловая система снова скопирует существующие блочные указатели и изменит копию. После этого файловая система обновит индексный дескриптор – в очередной раз изменяя копию – обращение к новому блоку непрямых указателей. После того, как эти действия были завершены, исходные данные и указатели остаются неизменными, но появятся новые блоки, непрямые указатели и индексный дескриптор для измененных данных:
Несколько следствий для файловой системы COW:
Суперблок – это общий корневой блок, содержащий индексные дескрипторы для битовых карт системы и индексные дескрипторы файлов. Файловая система Power-Safe поддерживает два суперблока:
Текущий суперблок может содержать блочные указатели на стабильный суперблок. Данные блоки содержат данные, которые еще не изменены, там формируются индексные дескрипторы и битовые карты.
Снапшот (snapshot) это согласованное представление файловой системы (просто переданный суперблок). Чтобы получить снапшот, файловая система:
При монтировании диска при запуске, файловая система просто считывает суперблоки с диска, проверяет правильность 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 – это последовательность основных операций:
O_CREAT | O_TRUNC для создания файла
Если файл настолько большой, что его копирование перекрывает снапшоты, появятся дисковые представления без этого файла, с файлом различной длины (размером) и, наконец с полностью скопированным файлом с его идентификаторами и правами доступа:
Каждый снапшот в настоящий момент времени просматривает файловую систему (например, при копировании 50 Мб, размер – 50 Мб, и все данные соответствующие 50 Мб будут скопированы и доступны). Если произойдет сбой питания, файловая система перезагрузит наиболее поздний снапшот. Но если у файловой системы нет порядка следования, действия open(), write() и close() – это одна высокоуровневая операция cp. Однако, если нужна высокоуровневая семантика, необходимо отключить снапшоты, на время действия cp, тогда они не будут возникать посреди операции, и если произойдет сбой питания, файл будет или полностью скопирован или не скопирован совсем.
Файловая система DOS ( fs-dos.so) обеспечивает прозрачный доступ к DOS-дискам. Если DOS не имеет своего эквивалента для какой-либо функции POSIX, модуль fs-dos.so либо вернет ошибку, либо предложит наиболее подходящее действие по умолчанию.
Например, попытка создания связи с помощью функции link() приведет к возврату соответствующей errno. С другой стороны, при попытке чтения POSIX-времени какого-либо файла модуль fs-dos.so возвратит вместо неподдерживаемого времени время последнего изменения.
Драйвер fs-dos.so поддерживает разделы как на гибких, так и на жестких дисках, созданные в различных версиях DOS — от DOS 2.1 до Windows 98.
В DOS каждая строка в текстовом файле завершается двумя символами (CR/LF), тогда как в POSIX-системах (и большинстве других систем) каждая строка завершается одним символом (LF). Следует отметить, что модуль fs-dos.so оставляет читаемые текстовые файлы неизменными и не преобразовывает их. Для большинства утилит и программ различие в формате завершения строки не имеет значения.
В некоторых очень старых DOS-программах для обозначения конца файла может использоваться символ Ctrl + Z (^Z). Этот символ также остается без изменений.
В DOS имя файла не может содержать ни один из следующих символов:
/ \ [ ] : * | + = ; , ?
При попытке создать файл с именем, содержащим какой-либо из этих недопустимых символов, будет возникать ошибка. Кроме того, в DOS-именах формата 8.3 все буквенные символы должны быть в верхнем регистре, поэтому при создании файлов модуль fs-dos.so отображает их имена в верхнем регистре. Однако для приложений в ЗОСРВ «Нейтрино» этот модуль по умолчанию преобразует файловые имена в нижний регистр, поэтому программы и пользователи ЗОСРВ «Нейтрино» всегда могут видеть и применять имена файлов в нижнем регистре (посредством опции sfn=sfn_mode).
Драйверу fs-dos.so можно задать один из следующих способов обработки длинных файловых имен (посредством опции lfn=lfn_mode):
При использовании опции 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-каталога, модуль fs-dos.so отображает метку тома в соответствии со значением, заданным для опции vollabel:
Файловая система 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 ( fs-cd.so) обеспечивает доступ к ресурсам 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 рассказывается далее в этой статье. |
Драйверы файловой системы FFS3 реализуют POSIX-подобную файловую систему на устройствах с флеш-памятью типа NOR. Эти драйверы являются автономными исполняемыми модулями, которые содержат программный код как для реализации файловой системы во флеш-памяти, так и для реализации работы устройства.
Существуют несколько версий драйверов файловой системы FFS3 для различного оборудования встраиваемых систем, а также для плат памяти PCMCIA.
Как правило, драйверы обозначаются именем devf-system, где system означает встраиваемую систему. Например, драйвер devf-800fads предназначен для отладочной платы 800FADS PowerPC.
Узнать, какие флеш-устройства поддерживаются в ЗОСРВ «Нейтрино» можно в разделе Драйверы.
Драйверы файловой системы FFS3 могут поддерживать одновременно несколько логических устройств хранения на флеш-памяти. Каждый логический диск называется сокетом (socket), он включает в себя некоторую непрерывную и однородную область флеш-памяти. Например, в системе, содержащей два разных типа флеш-устройств, расположенных по разным адресам и используемых для хранения загрузочного образа (одно устройство) и файловой системы (другое), каждое из этих устройств будет находиться в разных сокетах.
Каждый сокет может быть разбит на несколько разделов. Поддерживается два типа разделов:
Разделы с линейным доступом
Разделом с линейным доступом является любой раздел, не содержащий файловую систему для флеш-памяти. Драйвер не различает никаких других типов файловых систем, кроме того, который предназначен для флеш-памяти. Раздел с линейным доступом может содержать файловую систему загрузочного образа или данные приложений.
Посредством точки монтирования для устройств с линейным доступом (raw mountpoint) (см. далее) файловая система обеспечивает доступ ко всем разделам во флеш-памяти, которые не являются разделами с файловой системой. Необходимо отметить, что разделы с файловой системой также могут служить в качестве разделов с линейным доступом.
Разделы с файловой системой
Раздел с файловой системой содержит POSIX-подобную файловую систему во флеш-памяти, которая использует специальный формат QNX4 для хранения данных файловой системы на флеш-устройстве. Этот формат несовместим со спецификациями Microsoft FFS2 и PCMCIA FTL.
Файловая система FFS3 позволяет свободно создавать и удалять файлы и каталоги, а с помощью специального механизма восстановления (reclaim mechanism) пространство, освободившееся после удаления файлов, вновь становится доступным для использования.
Точки монтирования
При запуске драйвера файловой системы во флеш-памяти он по умолчанию присоединяет все разделы, которые находит в сокете. Тем не менее, можно задать точку монтирования с помощью утилиты mkefs или flashctl (например, /flash).
Файловая система 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 с атрибутом filter. Эту утилиту также можно использовать с целью предварительного сжатия данных, предназначенных для файловой системы во флеш памяти.
Менеджер ресурсов inflator расположен перед сжатыми (с помощью утилиты deflate) файловыми системами и позволяет почти вдвое увеличить полезный объем флеш-памяти.
Сжатые файлы можно обрабатывать с помощью стандартных утилит (например, cp или ftp). При использовании правильной точки монтирования утилита ls позволяет отобразить текущий и фактический размер сжатого файла. В результате работа со сжатыми файловыми системами становится практически прозрачной.
Ошибки во флеш-памяти
По мере износа микросхем флеш-памяти ее конечный автомат записи (write state-machine) может обнаружить, что запись или удаление некоторого бита невозможно. В этом случае драйверу файловой системы во флеш-памяти передается сообщение об ошибке для того, чтобы он применил соответствующее действие (т.е. отметил неисправную область и попытался выполнить операцию записи/стирания в другом месте).
Этот механизм обработки ошибок является прозрачным. Нужно отметить, что после нескольких подобных ошибок все операции записи и удаления, которые дают сбой, приведут к тому, что флеш-память станет доступной только для чтения. Тем не менее, это не должно случиться ранее, чем через несколько лет непрерывной работы. Для того чтобы рассчитать потенциальный срок жизни микросхемы флеш-памяти или ее параметр среднего времени наработки между отказами (MTBF), следует учитывать ее технические характеристики и объем потока данных, который производит система для этой микросхемы флеш-памяти.
Определение порядка следования байт
Файловая система FFS3 способна определять порядок следования байт (endian-awareness), что делает ее переносимой между разными платформами. Для выбора порядка следования байт оптимальной является утилита mkefs.
Файловая система FFS3 поддерживает все стандартные утилиты стандарта POSIX, в том числе ls, mkdir, rm, ln и cp. Кроме того, в ЗОСРВ «Нейтрино» для управления флеш-памятью предусмотрены и другие утилиты:
Файловая система 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.
Любые ограничения спецификации POSIX, существующие в файловой системе удаленного сервера, также будут переданы клиенту. Например, длина файловых имен может различаться на серверах в зависимости от операционной системы.
Файловая система NFS (версии 2 и 3) ограничивает файловые имена до 255 символов. Утилита mountd (версии 1 и 3) ограничивает файловые имена до 1024 символов.
Файловая система CIFS (Common Internet File System, общая файловая система Интернета), которая ранее называлась SMB (Server Message Block, блок серверных сообщений), позволяет клиентской рабочей станции получать прозрачный сетевой доступ к файлам на SMB-сервере. Клиентские запросы на доступ к файлам преобразуются в вызовы протокола CIFS и пересылаются на сервер через сеть. Сервер получает вызов, выполняет запрошенную файловую операцию и отправляет ответ клиенту.
Модуль fs-cifs использует протокол TCP/IP, поэтому для его работы необходимо также запустить модуль TCP/IP для ЗОСРВ «Нейтрино».
Файловая система Ext2 ( fs-ext2.so) обеспечивает доступ к дисковым разделам Linux. Эта реализация поддерживает стандартный набор возможностей, который имеется в файловой системе Ext2 версии 0 и 1.
Файловая система UDF (Universal Disk Format) обеспечивает доступ к таким записываемым носителям как CD, CD-R, CD-RW и DVD.
Файловая система UDF реализуется драйвером fs-udf.so.
| В реализации ЗОСРВ «Нейтрино» файловые системы UDF доступны только для чтения. |
Файловые системы 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 с журналированием), но только только в том случае, когда журнал «чистый», а не «грязный» вследствие некорректного завершения системы.
Доступ по чтению к файловым системам NTFS в системах ЗОСРВ «Нейтрино» обеспечивается разделяемым объектом fs-nt.so.
| В реализации ЗОСРВ «Нейтрино» файловые системы NTFS доступны только для чтения. |
ЗОСРВ «Нейтрино» предоставляет файловую систему Inflator для распаковки данных "на лету", которая представляет собой менеджер ресурсов inflator, регистрирующий свое путевое имя (префикс) перед другими файловыми системами и выполняющим распаковку файлов, ранее сжатых с помощью утилиты deflate.
Утилита inflator обычно используется в тех случаях, когда основной файловой системой является файловая система во флеш-памяти. Эта утилита позволяет почти вдвое увеличить полезный объем флеш-памяти.
Если файл открывается для чтения, утилита inflator делает попытку открыть этот файл с помощью основной файловой системы. Для этого утилита inflator читает первые 16 байт файла и проверяет их на наличие атрибута сжатия файла. Если этот атрибут определяется, утилита inflator становится промежуточным звеном между приложением и файловой системой. В результате все операции чтения возвращают изначальные данные файла в том виде, в котором он был до применения к нему операции сжатия.
Таким образом, с точки зрения приложения файл всегда остается несжатым. Утилита inflator поддерживает также произвольное позиционирование (random seeks). Если приложение вызывает функцию stat(), то она вернет размер распакованного файла (т.е. изначальный размер файла, который был до его сжатия).
Предыдущий раздел: перейти