API файловой системы - File system API

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

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

Каждая операционная система включает API-интерфейсы, необходимые для поддерживаемых файловых систем. Microsoft Windows имеет API файловой системы для NTFS и нескольких файловых систем FAT . Системы Linux могут включать API для ext2 , ext3 , ReiserFS и Btrfs, чтобы назвать несколько.

История

Некоторые ранние операционные системы были способны обрабатывать только ленточные и дисковые файловые системы . Они предоставили самый простой интерфейс с:

  • Пишите, читайте и размещайте

Для большей координации, такой как выделение и освобождение устройств, потребовалось добавить:

  • Открыть и закрыть

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

  • Управление метаданными
  • Обслуживание файловой системы

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

Для многопользовательских систем требуются API для:

  • Обмен
  • Ограничение доступа
  • Шифрование

Обзоры API

Пишите, читайте и размещайте

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

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

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

Открыть и закрыть

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

Обычные требования для запроса доступа к объекту файловой системы включают:

  1. Объект, к которому нужно получить доступ (файл, каталог, носитель и местоположение)
  2. Предполагаемый тип операций, выполняемых после открытия (чтение, обновление, удаление)

Может потребоваться дополнительная информация, например

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

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

Следует ожидать, что во время обработки открытия что-то может пойти не так.

  1. Объект или намерение могут быть указаны неправильно (имя может содержать недопустимый символ или намерение не распознано).
  2. Процессу может быть запрещен доступ к объекту (он может быть доступен только группе или конкретному пользователю).
  3. Файловая система может быть не в состоянии создавать или обновлять структуры, необходимые для координации действий пользователей.
  4. В случае нового (или заменяющего) объекта на носителе может не хватить емкости.

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

Закрытие может привести к отключению или извлечению съемного носителя и обновлению структур библиотеки и файловой системы, чтобы указать, что объект больше не используется. Минимальная спецификация для close ссылается на объект. Кроме того, некоторые файловые системы обеспечивают указание расположения объекта, которое может указывать на то, что объект должен быть удален и больше не является частью файловой системы. Подобно открытому, следует ожидать, что что-то может пойти не так.

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

Соображения по устранению сбоя аналогичны таковым при открытии.

Управление метаданными

Информация о данных в файле называется метаданными.

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

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

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

Управление каталогом

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

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

Обслуживание файловой системы

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

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

API уровня ядра

API является «уровнем ядра», когда ядро ​​не только предоставляет интерфейсы для разработчиков файловых систем, но также является пространством, в котором находится код файловой системы.

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

Это не самая чистая схема, но она решает проблемы серьезной перезаписи старой схемы.

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

Unix и Unix-подобные системы, такие как Linux , использовали эту модульную схему.

Существует вариант этой схемы, используемый в MS-DOS (начиная с DOS 4.0) и совместимый для поддержки CD-ROM и сетевых файловых систем. Вместо добавления кода в ядро, как в старой схеме, или использования средств ядра, как в схеме на основе ядра, он перехватывает все вызовы файла и определяет, следует ли его перенаправить на эквивалентную функцию ядра или нужно обрабатываться конкретным драйвером файловой системы, а драйвер файловой системы «напрямую» обращается к содержимому диска с помощью низкоуровневых функций BIOS .

API на основе драйверов

API «основан на драйвере», когда ядро ​​предоставляет средства, но код файловой системы находится полностью вне ядра (даже не как модуль модульного ядра).

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

Примерами этой схемы являются соответствующие IFS для Windows NT и OS / 2 .

Смешанный API на основе ядра и драйвера

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

Эта схема использовалась в Windows 3.1 для предоставления драйвера файловой системы FAT в 32-битном защищенном режиме и кэширования (VFAT), который полностью обходил драйвер DOS FAT в ядре (MSDOS.SYS), а также в более поздних версиях серии Windows 9x ( 95 , 98 и Me ) для VFAT, драйвер файловой системы ISO9660 (вместе с Joliet), общие сетевые ресурсы и драйверы файловой системы сторонних производителей, а также добавление к исходным API DOS API LFN (эти драйверы IFS могут не только перехватывать уже существующие существующие API-интерфейсы файлов DOS, но также добавляют новые из 32-разрядного исполняемого файла защищенного режима).

Однако этот API не был полностью задокументирован, и третьи стороны оказались в сценарии «сделай сам» даже хуже, чем с API на основе ядра.

API пользовательского пространства

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

Это полезно для работы с образами дисков.

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

Примерами этой схемы являются hfsutils и adflib .

Взаимодействие между API файловой системы

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

Например, драйвер ext2 для OS / 2 - это просто оболочка от VFS Linux для IFS OS / 2 и ядра ext2 в Linux, а драйвер HFS для OS / 2 - это порт hfsutils для OS / 2 IFS. Также существует проект, который использует драйвер Windows NT IFS для работы NTFS под Linux.

Смотрите также

Ссылки

Источники

  • О'Рейли - Внутреннее устройство файловой системы Windows NT, Руководство разработчика - Раджив Нагар - ISBN  1-56592-249-2
  • Microsoft Press - Внутри файловой системы Windows NT - Хелен Кастер - ISBN  1-55615-660-X
  • Wiley - Файловые системы UNIX: эволюция, проектирование и реализация - Стив Д. Пейт - ISBN  0-471-16483-6
  • Microsoft Press - Внутри Windows NT - Хелен Кастер - ISBN  1-55615-481-X

внешние ссылки