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

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

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

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

История

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

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

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

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

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

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

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

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

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

Обзоры API

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

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

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

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

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

В открыто 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 «основан на драйвере», когда ядро ​​предоставляет средства, но код файловой системы находится полностью вне ядра (даже не как модуль модульного ядра).

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

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

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

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

Эта схема использовалась в Windows 3.1 для предоставления драйвера файловой системы FAT в 32-битном[нужна цитата ] защищенный режим и кэширование (VFAT), который полностью обходил драйвер DOS FAT в ядре (MSDOS.SYS), а затем в Windows 9x серии (95, 98 и меня ) для VFAT, драйвер файловой системы ISO9660 (вместе с Joliet), общие сетевые ресурсы и драйверы файловой системы сторонних производителей, а также добавление к исходным DOS API LFN API (эти драйверы 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

внешняя ссылка