Loading article…
ファイルシステムAPIとは、ユーティリティプログラムやユーザープログラムがファイルシステムのサービスを要求するためのアプリケーションプログラミングインターフェースのことです。オペレーティングシステムは、異なるファイルシステムに透過的にアクセスするための抽象化機能を提供する場合があります。
ファイルシステムAPIの中には、ファイルシステムの作成や初期化、ファイルシステムの整合性の検証、デフラグなどのメンテナンス操作のためのインターフェースが含まれているものもあります。
各オペレーティングシステムには、サポートするファイルシステムに必要なAPIが含まれています。Microsoft Windowsには、 NTFSおよび複数のFATファイルシステム用のファイルシステムAPIがあります。Linuxシステムには、 ext2、ext3、ReiserFS、Btrfsなど、いくつかのファイルシステム用のAPIが含まれている場合があります。
初期のオペレーティングシステムの中には、テープファイルシステムとディスクファイルシステムしか扱えないものもあった。これらは、以下のような最も基本的なインターフェースを提供していた。
デバイスの割り当てや割り当て解除などの調整をさらに強化するには、以下の機能を追加する必要がありました。
ファイルシステムが提供するサービスが増えるにつれて、より多くのインターフェースが定義された。
ファイルシステムの種類、階層構造、サポートされるメディアが増えるにつれて、追加機能にはいくつかの特殊な機能が必要になった。
マルチユーザーシステムに必要なAPI：
ユーザーデータをファイルシステムに書き込む機能は、ユーザープログラムまたはランタイムライブラリが直接使用できるように提供されています。一部のプログラミング言語のランタイムライブラリは、型変換、フォーマット、およびブロッキング機能を提供する場合があります。一部のファイルシステムは、キーによるレコードの識別機能を提供し、既存のレコードの書き換え機能を含む場合があります。この操作は、場合によっては、PUTまたはPUTX（レコードが存在する場合）と呼ばれることがあります。
ユーザーデータの読み取り（GETと呼ばれることもある）には、方向（順方向または逆方向）が含まれる場合があり、キー付きファイルシステムの場合は特定のキーが含まれる場合もあります。書き込みと同様に、ランタイムライブラリがユーザープログラムに代わって処理を行う場合があります。
位置決めとは、次のレコードの位置を調整することです。これには、前方または後方へのスキップ、ファイルの先頭または末尾への位置決めなどが含まれます。
オープンAPIは、明示的に要求される場合もあれば、プロセスがオブジェクトに対して最初の操作を発行した際に暗黙的に呼び出される場合もあります。これにより、リムーバブルメディアのマウント、別のホストへの接続の確立、オブジェクトの場所とアクセス可能性の検証などが行われる可能性があります。また、オブジェクトが使用中であることを示すためにシステム構造が更新されます。
ファイルシステムオブジェクトへのアクセスを要求する際の一般的な要件は以下のとおりです。
追加情報が必要になる場合があります。例えば、以下のような情報です。
オープン処理中に何らかの問題が発生する可能性があることは想定しておく必要があります。
プログラミング言語によっては、open関数内の追加仕様によって、これらの状況を処理するモジュールが定義される場合があります。一部のライブラリでは、ファイルシステムへのライブラリモジュールを指定しており、何らかの障害によってオープンプログラムが意味のある処理を実行できなくなった場合に、分析を可能にするようになっています。
Closeコマンドを実行すると、リムーバブルメディアのマウント解除または排出、およびライブラリとファイルシステム構造の更新が行われ、オブジェクトが使用されなくなったことが示されます。closeコマンドの最小限の仕様は、オブジェクトを参照することです。さらに、一部のファイルシステムでは、オブジェクトの処分方法を指定する機能が提供されており、これにより、オブジェクトが破棄され、ファイルシステムの一部ではなくなることが示されます。
オープンと同様に、何らかの問題が発生する可能性も想定しておく必要がある。
障害発生時の対処に関する考慮事項は、オープンの場合と同様です。
ファイル内のデータに関する情報はメタデータと呼ばれます。
メタデータの一部はファイルシステムによって管理されます。例えば、最終更新日時（ファイルシステムによって異なるその他の日付も含む）、ファイルの先頭位置、ファイルサイズ、ファイルシステムのバックアップユーティリティがファイルの最新バージョンを保存したかどうかなどです。これらの項目は通常、ユーザープログラムによって変更することはできません。
一部のファイルシステムでサポートされている追加のメタデータには、ファイルの所有者、ファイルが属するグループ、権限とアクセス制御（つまり、さまざまなユーザーやグループが実行できるアクセスや更新内容）、およびディレクトリ一覧表示時にファイルが通常表示されるかどうかなどが含まれる場合があります。これらの項目は通常、所有者が実行できるファイルシステムユーティリティによって変更できます。
アプリケーションによっては、より多くのメタデータが保存されます。画像の場合、メタデータには、写真撮影に使用されたカメラの機種や設定が含まれる場合があります。音声ファイルの場合、メタデータには、アルバム、録音したアーティスト、録音に関するコメントが含まれる場合があります。コメントは、ファイルの特定のコピーに固有のものである可能性があります（つまり、同じ録音の異なるコピーには、ファイルの所有者によって更新された異なるコメントが含まれる場合があります）。ドキュメントには、チェック者、承認者などの項目が含まれる場合があります。
ファイルの名前変更、ファイル（またはサブディレクトリ）をあるディレクトリから別のディレクトリへ移動すること、ファイルの削除などは、ファイルシステムが提供するディレクトリ管理のための操作の例です。
通常、様々なユーザーまたはユーザーグループによるディレクトリへのアクセスを許可または制限するなどのメタデータ操作が含まれます。
ファイルシステムが使用されるにつれて、ディレクトリ、ファイル、レコードが追加、削除、または変更されることがあります。これは通常、基盤となるデータ構造の非効率性を引き起こします。例えば、論理的に連続したブロックがメディア全体に分散され、過剰な再配置が発生したり、部分的に使用されている、あるいは空のブロックがリンク構造に含まれたりするといった問題です。構造の不完全性やその他の不整合は、デバイスやメディアのエラー、停電の兆候の検出から実際の停電までの時間不足、不適切なシステムシャットダウンやメディアの取り外し、そしてごくまれにファイルシステムのコーディングエラーによって発生する可能性があります。
ファイルシステムには、これらの構造を最適化または修復するための専用ルーチンが含まれています。これらは通常、ユーザーが直接呼び出すのではなく、ファイルシステム自体の中でトリガーされます。構造のレベル数や挿入されたオブジェクトの数などの内部カウンタがしきい値と比較されます。これにより、特定の構造へのユーザーアクセスが一時停止される（通常は影響を受けるユーザーの不満を招く）か、優先度の低い非同期タスクとして開始されるか、ユーザーアクティビティの少ない時間に延期されることがあります。これらのルーチンは、システムマネージャによって呼び出されたり、スケジュールされたりする場合があり、デフラグメンテーションの場合も同様です。
APIがカーネルレベルであるというのは、カーネルがファイルシステム開発者向けのインターフェースを提供するだけでなく、ファイルシステムコードが存在する空間でもある場合を指します。
従来の方式と異なる点は、カーネル自体が独自の機能を使用してファイルシステムドライバと通信し、またその逆も同様であることです。従来の方式では、カーネルがファイルシステムのレイアウトを処理し、ファイルシステムがハードウェアに直接アクセスするという役割分担がされていました。
これは最も洗練された方法ではないが、従来の方法にあった大規模な書き換えに伴う困難を解決するものである。
モジュール型カーネルでは、ファイルシステムを任意のカーネルモジュールとして追加でき、サードパーティ製のものも追加可能です。しかし、非モジュール型カーネルでは、新しいファイルシステムコードを使用してカーネルを再コンパイルする必要があります（クローズドソースのカーネルでは、サードパーティ製のファイルシステムは使用できません）。
Unix系システムやLinuxなどのUnix系システムは、このモジュール方式を採用している。
MS-DOS （DOS 4.0以降）および互換機では、CD-ROMやネットワークファイルシステムをサポートするために、この方式のバリエーションが使用されています。従来の方式のようにカーネルにコードを追加したり、カーネルベースの方式のようにカーネルの機能を使用したりする代わりに、ファイルへのすべての呼び出しを捕捉し、カーネルの同等の機能にリダイレクトする必要があるか、特定のファイルシステムドライバで処理する必要があるかを識別します。そして、ファイルシステムドライバは低レベルのBIOS機能を使用してディスクの内容に直接アクセスします。
カーネルが機能を提供するものの、ファイルシステムコードがカーネルとは完全に外部に存在する場合（モジュール型カーネルのモジュールとしてさえ存在しない場合）、APIはドライバベースとなる。
ファイルシステムコードが完全に独立しているため、よりクリーンな方式と言えます。これにより、クローズドソースのカーネル向けにファイルシステムを作成したり、システムへのファイルシステムの追加や削除をオンラインで行ったりすることが可能になります。
この方式の例としては、Windows NTとOS/2それぞれのインストール可能ファイルシステム（IFS）が挙げられる。
このAPIでは、カーネルベースのAPIと同様に、すべてのファイルシステムはカーネル内に存在しますが、OSによってドライバベースの別のAPIによって自動的に捕捉されます。
ファイルシステムがカーネル機能を直接使用せず、高レベルのオペレーティングシステム関数を使用してディスクにアクセスする場合、APIはユーザー空間に存在し、一連のユーティリティがファイルシステムにアクセスするために使用する関数をライブラリとして提供します。
これはディスクイメージを扱う際に便利です。
利点は、ファイルシステムが使用する高レベルのオペレーティングシステム関数がANSI Cのように共通であるため、オペレーティングシステム間でファイルシステムを移植可能にできる点にあるが、欠点は、APIがそれを実装するアプリケーションごとに固有である点にある。
この方式の例としては、hfsutilsやadflibなどがあります。
すべてのディスクファイルシステムはカーネルによって提供される同等の機能を必要とするため、たとえ異なるタイプのAPIであっても、ファイルシステムコードをあるAPIから別のAPIへ容易に移植することが可能です。