ファイルシステムAPI

ファイルシステムAPI は、ユーティリティまたはユーザー プログラムがファイル システムのサービスを要求するための アプリケーション プログラミング インターフェイスです。オペレーティング システムは、さまざまなファイル システムに透過的にアクセスするための抽象化を提供する場合があります。

一部のファイル システム API には、ファイル システムの作成または初期化、ファイル システムの整合性の検証、デフラグなどのメンテナンス操作用のインターフェイスも含まれる場合があります。

各オペレーティング システムには、サポートするファイル システムに必要な API が含まれています。Microsoft Windowsには、 NTFSおよびいくつかのFATファイル システム用のファイル システム APIがあります。Linuxシステムには、 ext2、ext3、ReiserFS、Btrfsなどの API が含まれている場合があります。

初期のオペレーティング システムの中には、テープとディスクのファイル システムしか処理できないものもありました。これらのオペレーティング システムでは、次のような最も基本的なインターフェイスが提供されていました。

• 書く、読む、配置する

デバイスの割り当てや割り当て解除などのさらなる調整には、次の追加が必要でした。

• 開くと閉じる

ファイルシステムが提供するサービスが増えるにつれて、より多くのインターフェースが定義されました。

• メタデータ管理
• ファイルシステムのメンテナンス

追加のファイル システムの種類、階層構造、およびサポートされるメディアが増えるにつれて、追加機能にはいくつかの特殊な機能が必要になりました。

• ディレクトリ管理
• データ構造管理
• 記録管理
• 非データ操作

マルチユーザー システムでは次の API が必要です:

• 共有
• アクセス制限
• 暗号化

ユーザデータをファイルシステムに書き込む機能は、ユーザプログラムまたはランタイムライブラリによって直接使用されるように提供されています。一部のプログラミング言語のランタイムライブラリは、型変換、フォーマット、およびブロッキングを提供します。一部のファイルシステムは、キーによるレコードの識別を提供し、既存のレコードの書き換えを含む場合があります。この操作は、PUT またはPUTX(レコードが存在する場合) と呼ばれることがあります。

ユーザー データの読み取り (GET と呼ばれることもあります) には、方向 (順方向または逆方向) が含まれる場合があり、キー付きファイル システムの場合は特定のキーが含まれる場合があります。書き込みと同様に、ランタイム ライブラリがユーザー プログラムに介入する場合があります。

位置決めには、次のレコードの位置の調整が含まれます。これには、前方または後方へのスキップ、およびファイルの先頭または末尾への位置決めが含まれる場合があります。

オープンAPIは、オブジェクトに対するプロセスによる最初の操作の発行時に、明示的に要求されるか、または暗黙的に呼び出されます。これにより、リムーバブル メディアのマウント、別のホストへの接続の確立、オブジェクトの場所とアクセス可能性の検証が行われます。システム構造を更新して、オブジェクトが使用中であることを示します。

ファイル システム オブジェクトへのアクセスを要求するための通常の要件は次のとおりです。

1. アクセスするオブジェクト（ファイル、ディレクトリ、メディア、場所）
2. オープン後に実行される操作の種類（読み取り、更新、削除）

追加情報が必要な場合があります。例えば、

• パスワード
• オープンしているプロセスがオブジェクトを使用している間、他のプロセスが同じオブジェクトにアクセスできるという宣言 (共有)。これは、他のプロセスの意図に依存する場合があります。対照的に、他のプロセスの意図に関係なく、他のプロセスがオブジェクトにアクセスできないという宣言 (排他的使用)。

これらはプログラミング言語ライブラリを介して要求され、ファイル システムに要求を転送するだけでなく、プロセス内のモジュール間の調整も提供する場合があります。

オープン処理中に何か問題が発生する可能性が予想されます。

1. オブジェクトまたはインテントが不適切に指定されている可能性があります (名前に不適切な文字が含まれているか、インテントが認識されません)。
2. プロセスはオブジェクトへのアクセスを禁止されている可能性があります (グループまたは特定のユーザーのみがアクセスできる可能性があります)。
3. ファイル システムは、ユーザー間のアクティビティを調整するために必要な構造を作成または更新できない可能性があります。
4. 新しい（または交換用の）オブジェクトの場合、メディアの容量が十分でない可能性があります。

プログラミング言語によっては、オープンな追加仕様によって、これらの状態を処理するためのモジュールが確立される場合があります。一部のライブラリでは、ファイル システムにライブラリ モジュールを指定して、エラーの結果として開くプログラムが意味のあるアクションを実行できない場合に分析できるようにします。たとえば、必要な入力ファイルを開こうとしてエラーが発生した場合、エラーを報告してプログラムを中止するしかアクションがない場合があります。一部の言語では、エラーの種類を示すコードを返すだけで、常にプログラムでチェックして、何を報告し、続行できるかを判断します。

閉じると、リムーバブル メディアがマウント解除または取り出され、ライブラリとファイル システム構造が更新されて、オブジェクトが使用されなくなったことが示されます。閉じるには、オブジェクトを参照する最小限の指定が必要です。さらに、一部のファイル システムでは、オブジェクトの処理を指定できるため、オブジェクトが破棄され、ファイル システムの一部ではなくなる可能性があります。開くと同様に、何か問題が発生する可能性を想定する必要があります。

1. オブジェクトの指定が間違っている可能性があります。
2. バッファリングされているデータを保存したり、オブジェクトが正常に更新されたことを示す構造を出力するのに十分な容量がメディアにない可能性があります。
3. バッファリングされたデータ、完了構造の書き込み中、またはオブジェクトに関連するメタデータ (最終アクセス時間など) の更新中に、オブジェクトが保存されているメディアでデバイス エラーが発生する場合があります。
4. オブジェクトを解放する仕様は、そのオブジェクトをまだ使用している他のプロセスと一致しない可能性があります。

障害の処理に関する考慮事項は、オープンの場合と同様です。

ファイル内のデータに関する情報はメタデータと呼ばれます。

メタデータの一部はファイル システムによって管理されます。たとえば、最終変更日 (およびファイル システムによって異なるその他のさまざまな日付)、ファイルの先頭の位置、ファイルのサイズ、ファイル システム バックアップ ユーティリティがファイルの現在のバージョンを保存したかどうかなどです。これらの項目は通常、ユーザー プログラムによって変更することはできません。

一部のファイル システムでサポートされている追加のメタデータには、ファイルの所有者、ファイルが属するグループ、権限やアクセス制御 (さまざまなユーザーやグループが実行できるアクセスと更新)、ディレクトリが一覧表示されたときにファイルが通常表示されるかどうかなどが含まれます。これらの項目は通常、所有者が実行できるファイル システム ユーティリティによって変更できます。

アプリケーションによっては、より多くのメタデータを保存します。画像の場合、メタデータには、写真撮影に使用されたカメラのモデルと設定が含まれることがあります。オーディオ ファイルの場合、メタデータには、アルバム、録音したアーティスト、ファイルの特定のコピーに固有の録音に関するコメントが含まれることがあります (つまり、同じ録音の異なるコピーには、ファイルの所有者による更新に応じて異なるコメントが含まれることがあります)。ドキュメントには、確認者、承認者などの項目が含まれることがあります。

ファイルの名前変更、ファイル (またはサブディレクトリ) をあるディレクトリから別のディレクトリに移動、およびファイルの削除は、ディレクトリの管理のためにファイル システムによって提供される操作の例です。

通常、さまざまなユーザーまたはユーザー グループによるディレクトリへのアクセスを許可または制限するなどのメタデータ操作が含まれます。

ファイルシステムを使用すると、ディレクトリ、ファイル、レコードが追加、削除、または変更されることがあります。これにより、通常、基礎となるデータ構造の効率が低下します。論理的に連続したブロックがメディア全体に分散され、過度の再配置が発生する、部分的に使用されているブロックやリンクされた構造に含まれる空のブロックなどです。不完全な構造やその他の不整合は、デバイスまたはメディアのエラー、差し迫った電源喪失の検出と実際の電源喪失の間の不十分な時間、不適切なシステムシャットダウンまたはメディアの取り外し、および非常にまれなケースではファイルシステムのコーディングエラーによって発生する可能性があります。

ファイル システムには、これらの構造を最適化または修復するための専用ルーチンが含まれています。通常、これらのルーチンはユーザーによって直接呼び出されるのではなく、ファイル システム自体の内部でトリガーされます。構造のレベル数、挿入されたオブジェクトの数の内部カウンターがしきい値と比較される場合があります。これにより、特定の構造へのユーザー アクセスが一時停止されることがあります (通常、影響を受けるユーザーまたは複数のユーザーに迷惑がかかります)。また、優先度の低い非同期タスクとして開始されるか、ユーザー アクティビティが少ない時間に延期されることがあります。これらのルーチンは、システム マネージャーによって呼び出されたりスケジュールされたりすることがあります。また、デフラグの場合も同様です 。

カーネルがファイルシステム開発者向けのインターフェースを提供するだけでなく、ファイルシステム コードが存在するスペースでもある場合、API は「カーネル レベル」になります。

カーネル自体が独自の機能を使用してファイルシステム ドライバーと通信し、その逆もまた同様であるという点で、古いスキーマと異なります。これは、カーネルがファイルシステムのレイアウトを処理し、ファイルシステムがハードウェアに直接アクセスするのとは対照的です。

これは最もクリーンなスキームではありませんが、古いスキームを大幅に書き直す際の困難を解決します。

モジュラー カーネルでは、サード パーティのカーネル モジュールであっても、任意のカーネル モジュールとしてファイルシステムを追加できます。ただし、非モジュラー カーネルでは、新しいファイルシステム コードを使用してカーネルを再コンパイルする必要があります (クローズド ソース カーネルでは、これによりサード パーティのファイルシステムは不可能になります)。

UnixやLinuxなどのUnix 系システムでは、このモジュール方式が使用されています。

この方式のバリエーションは、 CD-ROM およびネットワーク ファイル システムをサポートするために、MS-DOS (DOS 4.0 以降) および互換機で使用されています。古い方式のようにカーネルにコードを追加したり、カーネル ベースの方式のようにカーネル機能を使用したりするのではなく、ファイルへのすべての呼び出しをトラップし、カーネルの同等の機能にリダイレクトする必要があるか、特定のファイル システム ドライバーで処理する必要があるかを識別し、ファイル システム ドライバーは低レベルのBIOS機能を使用してディスクの内容に「直接」アクセスします。

カーネルが機能を提供するものの、ファイル システム コードが完全にカーネルの外部に存在する場合 (モジュラー カーネルのモジュールとしてでない場合)、API は「ドライバー ベース」になります。

ファイルシステム コードが完全に独立しているため、よりクリーンなスキームであり、クローズド ソース カーネル用のファイルシステムの作成や、システムへのオンライン ファイルシステムの追加または削除が可能になります。

この方式の例としては、Windows NTとOS/2のそれぞれのIFSがあります。

この API では、カーネルベースの API と同様に、すべてのファイルシステムがカーネル内にありますが、OS によってドライバーベースの別の API によって自動的にトラップされます。

この方式は、Windows 3.1で、カーネル (MSDOS.SYS) 内の DOS FAT ドライバーを完全にバイパスする32 ビット^{[引用が必要]保護モードおよびキャッシュ (VFAT) の FAT ファイルシステム ドライバーを提供するために使用され、その後、Windows 9x シリーズ (} 95、98、およびMe ) では、VFAT、ISO9660 ファイルシステム ドライバー (Joliet とともに)、ネットワーク共有、およびサード パーティのファイルシステムドライバーに使用され、オリジナルの DOS API に LFN API が追加されました (IFS ドライバーは、既存の DOS ファイル API を傍受できるだけでなく、32 ビット保護モード実行可能ファイル内から新しい API を追加することもできます)。

しかし、その API は完全に文書化されておらず、サードパーティはカーネルベースの API の場合よりもさらに悪い「自分で作る」シナリオに陥っていました。

ファイルシステムがカーネル機能を直接使用せず、高レベルのオペレーティング システム機能を使用してディスクにアクセスし、一連のユーティリティがファイルシステムにアクセスするために使用するライブラリ内の機能を提供する場合、APIはユーザー空間にあります。

これはディスクイメージの処理に便利です。

利点は、使用する高レベルのオペレーティング システム関数が ANSI C と同じくらい一般的なので、ファイル システムをオペレーティング システム間で移植可能にできることですが、欠点は、API がそれを実装するアプリケーションごとに固有になることです。

このスキームの例としては、hfsutils と adflib ^{[ permanent dead link ‍ ]}があります。

すべてのファイルシステム (少なくともディスクファイルシステム) はカーネルによって提供される同等の機能を必要とするため、異なるタイプであっても、ある API から別の API にファイルシステム コードを簡単に移植できます。

たとえば、OS/2 用の ext2 ドライバーは、Linux の VFS から OS/2 の IFS および Linux の ext2 カーネルベースへの単なるラッパーであり、OS/2 用の HFS ドライバーは、hfsutils を OS/2 の IFS に移植したものです。また、Windows NT IFS ドライバーを使用して Linux で NTFS を動作させるプロジェクトも存在します。

• ファイルシステムの比較
• ファイルシステム
• ファイル名拡張子
• オープンサービスインターフェース定義(OSID)の提出
• インストール可能なファイルシステム(IFS)
• ファイルシステムのリスト
• 仮想ファイルシステム

• O'Reilly - Windows NT ファイル システムの内部、開発者ガイド - Rajeev Nagar 著 - ISBN  1-56592-249-2
• Microsoft Press - Windows NT ファイル システムの内部 - Helen Custer 著 - ISBN 1-55615-660-X 
• Wiley - UNIX ファイルシステム: 進化、設計、実装 - 著者: Steve D. Pate - ISBN 0-471-16483-6 
• Microsoft Press - Inside Windows NT - 著者: Helen Custer - ISBN 1-55615-481-X 

• ファイルシステムの仕様と技術ホワイトペーパーは、2015 年 11 月 3 日にWayback Machineにアーカイブされました。
• Linux VFS のツアー
• Microsoft の IFSKit
• hfsutils
• adflib ^{[永久リンク切れ‍ ]}
• Go 用のファイルシステム抽象化システム