iノード

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

iノード(インデックスノード)は、ファイルディレクトリなどのファイルシステムオブジェクトを記述するUnixスタイルのファイルシステムデータ構造です各iノードは、オブジェクトのデータの属性とディスクブロックの場所を格納します。[1]ファイルシステムオブジェクトの属性には、メタデータ([2]最後の変更時刻、[2]アクセス、変更)、および所有者とアクセス許可のデータが含まれる場合があります。[3]

ディレクトリは、割り当てられた名前を持つiノードのリストです。このリストには、それ自体、その親、およびその各子のエントリが含まれています。

語源

Linuxカーネルメーリングリストには、「inode」の「i」の理由について 不確実性があります。2002年に、この質問はUnixのパイオニアであるDennis Ritchieに持ち込まれ、次のように答えました。[4]

実は私も知りません。それは私たちが使い始めた単なる用語でした。「インデックス」は、ファイルのアクセス情報をディスク上にフラットな配列として格納し、すべての階層ディレクトリ情報がこれとは別に存在する、少し変わったファイルシステム構造のため、私の推測です。したがって、i番号はこの配列のインデックスであり、iノードは配列の選択された要素です。(第1版のマニュアルでは、「i-」表記が使用されていました。ハイフンは徐々に削除されました。)

RitchieとKenThompsonによる1978年の論文、「インデックス」がiノードの語源的起源であるという概念を支持しています。彼らは書いた:[5]

[…]ディレクトリエントリには、関連付けられたファイルの名前とファイル自体へのポインタのみが含まれます。このポインタは、ファイルのi番号(インデックス番号)と呼ばれる整数です。ファイルにアクセスすると、そのi番号は、ディレクトリが存在するデバイスの既知の部分に格納されているシステムテーブル( i-list )へのインデックスとして使用されます。それによって見つかったエントリ(ファイルのiノード)には、ファイルの説明が含まれています。

さらに、Maurice J. Bachは、iノードは「インデックスノードという用語の短縮形であり、UNIXシステムに関する文献で一般的に使用されている」と書いています。[6]

詳細

Unixのファイル記述子、ファイルテーブル、iノードテーブル[7]

ファイルシステムは、そのファイルの内容ではなく、ファイルに関するデータ構造に依存しています。前者はメタデータと呼ばれ、データを説明するデータです。各ファイルはiノードに関連付けられています。iノードは整数で識別され、多くの場合、i番号またはiノード番号と呼ばれます。

iノードは、ファイルの所有権、アクセスモード(読み取り、書き込み、実行のアクセス許可)、ファイルの種類など、ファイルとディレクトリ(フォルダー)に関する情報を格納します。多くの古いファイルシステムの実装では、iノードの最大数はファイルシステムの作成時に固定されており、ファイルシステムが保持できるファイルの最大数が制限されています。ファイルシステム内のiノードの一般的な割り当てヒューリスティックは、ファイルシステムに含まれる2Kバイトごとに1つのiノードです。[8]

iノード番号は、デバイス上の既知の場所にあるiノードのテーブルにインデックスを付けます。iノード番号から、カーネルのファイルシステムドライバは、ファイルの場所を含むiノードの内容にアクセスできるため、ファイルにアクセスできます。ファイルのiノード番号は、コマンドを使用して見つけることができますls -iこのls -iコマンドは、レポートの最初の列にiノード番号を出力します。

ZFSOpenZFSReiserFSbtrfsAPFSなどの一部のUnixスタイルのファイルシステムでは、固定サイズのiノードテーブルが省略されていますが、同等の機能を提供するには、同等のデータを格納する必要があります。データは、プログラムにデータを提供するstat システムコールを参照して、統計データと呼ばれる場合があります。固定サイズのテーブルの一般的な代替手段には、Bツリーと派生B +ツリーがあります。

ファイル名とディレクトリへの影響:

  • iノードにはハードリンク名は含まれず、他のファイルメタデータのみが含まれます。
  • Unixディレクトリは、関連付け構造のリストであり、各ディレクトリには1つのファイル名と1つのiノード番号が含まれています。
  • ファイルシステムドライバは、特定のファイル名を探すディレクトリを検索してから、ファイル名を対応する正しいiノード番号に変換する必要があります。

このデータのオペレーティングシステムカーネルのメモリ内表現は、 Linuxではstruct inode呼び出されます。BSDから派生したシステムでは、この用語を使用します(「v」は、カーネルの仮想ファイルシステム層を指します)。 vnode

POSIXiノードの説明

POSIX標準は、従来のUNIXファイルシステムの影響を強く受けるファイルシステムの動作を義務付けていますiノードは「ファイルシリアル番号」というフレーズで表され、ファイルごとのファイルシステムの一意の識別子として定義されます。[9]そのファイルのシリアル番号は、ファイルを含むデバイスのデバイスIDとともに、システム全体でファイルを一意に識別します。[10]

POSIXシステム内では、ファイルには次の属性[10]statがあり、システムコール によって取得できます。

  • デバイスID(これは、ファイルを含むデバイス、つまり、シリアル番号の一意性の範囲を識別します)。
  • ファイルのシリアル番号。
  • ファイルの種類と、ファイルの所有者、そのグループ、およびその他のユーザーがファイルにアクセスする方法を決定するファイルモード。
  • iノードを指すハードリンクの数を示すリンク数。
  • ファイルの所有者のユーザーID 。
  • ファイルグループID 。
  • デバイスファイルの場合は、ファイルのデバイスID
  • ファイルのサイズ(バイト単位) 。
  • iノード自体が最後に変更された日時(ctimeiノード変更時刻)、ファイルの内容が最後に変更された日時(mtime変更時刻)、および最後にアクセスされた時刻(atimeaccess time )を示すタイムスタンプ
  • 推奨されるI / Oブロックサイズ。
  • このファイルに割り当てられたブロックの数。

含意

iノードで設計されたファイルシステムには、次の管理上の特徴があります。

  • ファイルには複数の名前を付けることができます。複数の名前が同じiノードにハードリンクしている場合、その名前は同等です。つまり、最初に作成されるものには特別なステータスはありません。これは、iノード(番号)ではなく元の名前に依存するシンボリックリンクとは異なります。
  • iノードにはリンクがない場合があります。リンクされていないファイルはディスクから削除され、そのリソースは再割り当てのために解放されますが、削除は、ファイルを開いたすべてのプロセスがファイルへのアクセスを完了するまで待機する必要があります。これには、実行可能ファイルを実行するプロセスによって暗黙的に開かれたままにされる実行可能ファイルが含まれます。
  • 通常、開いているファイルから、そのファイルを開くために使用されたファイル名にマップすることはできません。オペレーティングシステムはすぐにファイル名をiノード番号に変換し、ファイル名を破棄します。つまり、getcwd()およびgetwd()ライブラリ関数は、親ディレクトリを検索して、作業ディレクトリに一致するiノードを持つファイルを見つけ、次にそのディレクトリの親を検索し、ルートディレクトリに到達するまで続けます。SVR4およびLinuxシステムは、これを可能にするために追加情報を維持します。
  • 歴史的に、ディレクトリをハードリンクすることは可能でした。これにより、ディレクトリ構造は、有向非巡回グラフとは対照的に、任意の有向グラフになりました。ディレクトリがそれ自体の親になることさえ可能でした。最近のシステムでは、rootの親まだrootとして定義されている場合を除いて、一般にこの紛らわしい状態を禁止しています。この禁止事項の最も顕著な例外は、スーパーユーザーがディレクトリのハードリンクを作成できるMac OS X (バージョン10.5以降)にあります。[11]
  • ファイルのiノード番号は、同じデバイス上の別のディレクトリに移動した場合、またはディスクが最適化されて物理的な場所が変更された場合でも同じままであるため、ファイルの読み取りと書き込みを中断することなく、ファイルの移動と名前の変更が可能です。 。これは、 FATやその子孫など、ファイルのディレクトリエントリとそのデータの両方が移動されたときにこの不変性を保存する方法がない多くの非Unixファイルシステムでは、完全に準拠したiノードの動作を実装できないことも意味します。
  • iノードファイルシステムを使用すると、新しいライブラリのインストールが簡単になります。実行中のプロセスはライブラリファイルにアクセスできますが、別のプロセスがそのファイルを置き換えて新しいiノードを作成します。新しいファイルにはまったく新しいマッピングが存在するため、その後ライブラリにアクセスしようとすると新しいバージョンが取得されます。この機能により、現在マップされているライブラリを置き換えるために再起動する必要がなくなります。
  • デバイスがiノードを使い果たす可能性があります。この場合、空き容量がある場合でも、デバイス上に新しいファイルを作成することはできません。これは、多くの小さなファイルを含むメールサーバーのようなユースケースで最も一般的です。ファイルシステム(JFSXFSなど)は、エクステントまたは動的iノード割り当てによってこの制限を回避します。これにより、ファイルシステムが「成長」したり、iノードの数が増えたりする可能性があります。

インライン化

スペース(データブロックは不要)とルックアップ時間(ディスクアクセスは不要)の両方を節約するために、非常に小さなファイルをiノード自体に格納することは理にかなっています。このファイルシステム機能はインライン化と呼ばれます。したがって、最新のファイルシステムを使用する場合、iノードとファイルデータの厳密な分離は想定できなくなります。

ファイルのデータがデータへのポインタに割り当てられたスペースに収まる場合、このスペースを便利に使用できます。たとえば、ext2とその後継は、データが60バイト(「高速シンボリックリンク」)以下の場合、この方法でシンボリックリンク(通常はファイル名)のデータを保存します。[12]

Ext4inline_dataには、ファイルシステムの作成中に有効にした場合にext4がインライン化を実行できるようにするというファイルシステムオプションがあります。iノードのサイズには制限があるため、これは非常に小さいファイルに対してのみ機能します。[13]

Unix以外のシステムでは

  • NTFSには、Bツリーにファイルを格納するマスターファイルテーブル(MFT)があります。各エントリには、このエントリを一意に参照するiノード番号に類似した「fileID」があります。[14] 3つのタイムスタンプ、デバイスID、属性、参照カウント、およびファイルサイズがエントリにありますが、POSIXとは異なり、アクセス許可は異なるAPIを介して表現されます。[15]ディスク上のレイアウトはより複雑です。[16]以前のFATファイルシステムにはそのようなテーブルがなく、ハードリンクを作成することができませんでした。
    • NTFSには、小さなファイルをMFTエントリにインライン化するという概念もあります。[17]
    • 派生したReFSには相同なMFTがあります。ReFSには128ビットのファイルIDがあります。この拡張機能は、元々64ビットのファイルIDを持っていたNTFSにもバックポートされました。[15]
  • 同じ統計情報のようなGetFileInformationByHandleAPIをクラスター共有ボリュームSMB3.0で使用できるため、これらのシステムはおそらくファイルIDの同様の概念を持っています。[15]

も参照してください

参考文献

  1. ^ タネンバウム、アンドリューS.モダンオペレーティングシステム(第3版)。p。279。
  2. ^ JVSANTEN。「mtime、ctime、atimeの違い-LinuxのハウツーとFAQ」LinuxのハウツーとFAQ
  3. ^ 「Linux仮想ファイルシステムスイッチの構造」ibm.com
  4. ^ Linuxカーネルリストアーカイブ2011年1月12日に取得。
  5. ^ リッチー、デニスM。; トンプソン、ケン(1978)。「UNIXタイムシェアリングシステム」ベルシステムテクニカルジャーナル57(6):1913–1914 2015年12月19日取得
  6. ^ モーリスJ.バッハ(1986)。UNIXオペレーティングシステムの設計プレンティスホール。ISBN 978-0132017992
  7. ^ バッハ、モーリスJ.(1986)。UNIXオペレーティングシステムの設計プレンティスホール。p。94. Bibcode1986duos.book ..... B。
  8. ^ "linfo"Linux情報プロジェクト2020年3月11日取得
  9. ^ 「定義-3.176ファイルのシリアル番号」オープングループ2018年1月10日取得
  10. ^ a b "<sys /stat.h>"オープングループ2018年1月15日取得
  11. ^ 「OSXのディレクトリへのハードリンクを作成するためのUnixコマンドとは何ですか?」スタックオーバーフロー2011年1月16日。 2020年1月5日のオリジナルからアーカイブ2020年1月5日取得
  12. ^ 「Linuxカーネル:ファイルシステム」tue.nl。 _
  13. ^ 「Ext4ディスクレイアウト」kernel.org 2013年8月18日取得
  14. ^ 「WindowsにはLinuxのようなiノード番号がありますか?」スタックオーバーフロー
  15. ^ a b c "GetFileInformationByHandle関数(fileapi.h)-Win32アプリ"docs.microsoft.com
  16. ^ "[MS-FSCC]:NTFS属性タイプ"docs.microsoft.com
  17. ^ 「Windows-NTFSマスターファイルテーブル(MFT)に完全に保存できるファイルの最大サイズ」

外部リンク