ディレクトリのiノードがファイル名をext4ファイルシステムに保存するのはなぜですか？
ディレクトリのiノードは通常のファイルのiノードのそれと実質的に違いはありません。私が Ext4 Disk Layout から理解できることは次のとおりです。
ディレクトリエントリ ：したがって、ディレクトリは一連のデータブロックであり、各ブロックにはディレクトリエントリの線形配列が含まれていると言う方がより正確です。
ディレクトリエントリには、ファイル名とそのiノードへのポインタが格納されます。したがって、ドキュメントに各ブロックにディレクトリエントリが含まれていると記載されている場合、debugfsがディレクトリのiノードに保存されているファイル名とは異なる何かを報告するのはなぜですか？これは、ext4フォーマットのフラッシュドライブのデバッグセッションです。
debugfs: cat /sub
�
.
..�
spam�spam2�spam3��spam4
inode_i_blockがそれらのファイル名を保存できないと思います。60バイトを超える非常に長いファイル名のファイルを作成しました。 catのiノードでdebugfsを実行すると、ファイル名も表示されたため、長いファイル名が再びiノードにありました。
Iノードが記述するファイルのタイプに応じて、
inode.i_blockの60バイトのストレージはさまざまな方法で使用できます。一般に、通常のファイルとディレクトリはファイルブロックのインデックス情報に使用し、特別なファイルは特別な目的に使用します。
また、新しい実装である Hash Tree Directories セクションにファイル名を格納するiノードへの参照はありません。そのドキュメントで何かを見逃しているように感じます。
主な質問は、ディレクトリのiノードにファイル名が含まれている場合、そのデータブロックには何が格納されるのでしょうか。
ディレクトリエントリは両方に格納されますinode.i_blockおよびデータブロック。リンクしたドキュメントの「インラインデータ」と「インラインディレクトリ」を参照してください。
catはファイルcontentsを出力します。つまり、データブロックです。 _/bin/cat_に似ています。
catコマンドは、iノード構造のバイトを端末に書き込んだ場合は役に立ちません。 _inode_dump_とstatを比較します。
一部のドキュメントでは、歴史的なUNIXで許可されていることが説明されています。 _/bin/cat_を使用してこのデータを読み取ります。これは、ユーザー空間からディレクトリエントリを一覧表示する元の方法でした。つまりlsはディレクトリを開き、read()はエントリを解釈して解釈します。 readdir()を使用するのとは対照的に、カーネルは、基になるファイルシステムの形式に関係なく、標準形式でエントリを提供します。
ディレクトリのデータには direntエントリ が含まれています。各ディレクトリエントリには、ファイル名とiノードへのポインタが含まれています。 ext4 iノードには、効率を上げるために小さなファイルのデータ内容を含めることができるため、さらに別のブロック読み取りを実行する必要がありません。
"small"の値 は、ファイル属性では60バイト、拡張ファイル属性が使用されていない場合は最大160バイトです。
マニュアルページの言語が混乱しているとは思いますが、debugfs catコマンドがiノード自体の内容を表示するとは思いません。多くの場所で、manページは「inodeファイル仕様」を参照しています。これは、ファイル仕様はパス名またはiノード番号のいずれかであることを読者に思い出させる冗長な方法だと思います。 manページからの以下の抜粋を比較してください。
ネコfilespec -iノードの内容をダンプする filespec stdoutへ。
statfilespec -iノードのiノード構造の内容を表示する filespec。
Catは「inode filespec」の内容を表示していると思いますが、inode、filespecの内容は表示していません。ファイル名は、iノードではなく、データブロックに明確にリストされています。