興味深いアイデアです。
私は ext3 に詳しくありませんが、いくつかの一般的な指針を示すことができます。
現在、ext3 は inode を所定の場所に格納します。各ブロック グループには、inode の配列である独自の inode テーブルがあります。そのため、i ノード番号がある場合 (つまり、ディレクトリ内のファイル名を検索した結果として)、最初に i ノード番号を使用して正しいブロック グループを選択し、次にそのブロックにインデックスを付けると、ディスク上で対応する i ノードを見つけることができます。グループの inode テーブル。
対応するファイル データの隣に i ノードを配置する場合は、ディスク上で i ノードを見つけるための新しいスキームが必要になります。各 i ノード専用のブロックを用意する場合、考えられる 1 つの方法は、i ノードが必要になるたびに新しいブロックを割り当て、そのブロック番号を i ノード番号として使用することです。これには、小さなファイルの場合、データを同じブロックに格納できるという利点がある場合があります。
このようなことを実現するには、新しいファイルの作成 (i ノードの割り当て) が、現在の ext3 ファイル システムとはまったく異なる方法で行われる必要があります。ビットマップを使用して、未使用で事前に割り当てられ、事前に初期化された inode を見つける代わりに、空のブロックを割り当てて自分で初期化する必要があります。そのため、ファイル システムがファイルへの書き込み時にどのようにブロックを割り当てるかを確認し、それを模倣して i ノードを割り当てることをお勧めします。
別の方法として、i ノードをディレクトリ内に格納する方法があります。したがって、I/O を保存するのは、inode がそのデータの隣にあるからではなく、ファイル名を検索するときに inode も読み取るためです。これは 90 年代に BSD の FFS ファイル システムの実験として行われ、優れたUSENIX 論文にまとめられました。これらのアイデアは FFS にも、私が知っている他のメイン ストリーム ファイル システムにも反映されていません。
これらのスキームのいずれかを追求するか、独自のものを考え出すかに関係なく、mke2fsを変更して、新しいファイル システム バリアントが理解できる方法でディスク上のファイル システムを初期化する必要もあります。
幸運を!楽しいプロジェクトのようですね。