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

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

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

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

История

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

Пишите, читайте и позиционируйте

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

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

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

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

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

Управление каталогом
Управление структурой данных
Управление записями
Операции без данных

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

Совместное использование
Ограничение доступа
Шифрование

Обзоры API

Пишите, читайте и позиционируйте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 и 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. 2-й IFS. Также существует проект, который использует драйвер Windows NT IFS для работы NTFS под Linux.

См. также

Ссылки

Источники

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

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