私はまた、マルチレベルのページ付けでも同じ混乱を経験しました。インデックスノードの場合、データブロックへの直接および間接ポインタがあります。ただし、小さなファイルの場合は、目的に合わせてより多くのポインタを保存できるため、間接ポインタを使用することをお勧めします。
しかし、なぜ1つのレイヤーに直接ポインタを順番に保存するとより多くのデータが消費されますが、間接ポインタを使用するとより少ないデータが消費されますか？もちろん、すべてのポインタはファイルシステムのどこかに存在し、同じ量のスペースを占有しなければなりません。そうですか？この余分なスペースはどこから来ますか？
私の考えの例は次のとおりです。それぞれ128ポインタと128^2ポインタを指す10個の直接ポインタと2個の間接ポインタがある場合、消費される合計サイズは10 + 128 + 128^2ダイレクトポインタと同じですか？そうでなければ、スペースを節約する方法は何ですか？
追加の質問として、inodeの一般的なサイズはいくらですか？ inodeのサイズがなぜ違うのですか？
ベストアンサー1
inodeレベルの元の階層はおおよそ次のようになります。
1つまたは複数のブロック番号をinodeに直接保存できます。つまり、inodeにさらに数バイトを使用しますが、小さなファイルの場合、ほとんど空のブロック全体を割り当てる必要はありません。
次のステップは間接アドレス指定です。つまり、ブロックポインタを格納するブロックを割り当てます。この間接ブロックのアドレスのみがinodeに格納されます。これは何らかの形で「少ないスペース」を使用せず、ほとんどのファイルシステム、さらには初期システムもこのように機能します（inode /ファイル名の近くにブロックを指すポインタがあり、ブロックはファイルのブロック番号を格納します）。
しかし、このブロックにスペースが足りない場合はどうすればよいですか？別のブロックを割り当てる必要がありますが、このブロックへの参照はどこに保存されますか？これらの参照をinodeに追加するだけですが、大きなファイルを保存するにはinodeが大きくなります。そして、できるだけ多くのinodeが単一のブロックに入ることができるように、より小さなinodeを望んでいます（より少ない数のinodeを読み取るためのより少ないディスクアクセス）。
したがって、2段階間接ブロックを使用します。一つinodeへのポインタがある場合、ファイル自体のブロックアドレスを格納する間接ブロックへのポインタを格納する完全なブロックがあります。
そして、より高いレベルの間接ブロックを追加するか、目的の構造のファイルが可能な最大サイズに達するまで、特定のステップで停止できます。
したがって、ポイントは、「全体的に少ないスペースを使用すること」ではありません。を使用することです。
一方、ページテーブルはかなり異なる動作をします。
編集する
コメントの質問に答えてください。
データブロックは、デフォルトのハードディスクブロックサイズの倍数である固定サイズ（元の512バイト、IIRC）を持ちます。したがって、データブロックサイズを「減らす」ことはできません。
上記のように、inodeがあまりにも多くのスペースを占有しないようにする全体的な目的は次のとおりです。インデックスノードへのアクセスが高速です。（またはキャッシュされたinodeがメモリを少なくします。inodeを持つUnixファイルシステムが発明されたとき、たくさん今日よりメモリが少ない。）いいえどういうわけか全体のスペースを節約する方法。自分が言ったように、すべてはどこかに保存する必要があります。位置Xのスペースを使用しない場合は、位置Yのスペースを使用します。
単に inode に可変個数のブロックポインタを追加するのは、inode が固定された空間を占める必要があるため、非実用的です。 inode番号を使用して、inode情報が格納されているブロック内のブロックアドレスとオフセットを計算します。各inodeのサイズが異なる場合は、これを行うことはできません。だから、一部間接的な形。
ページテーブルは、ハードウェアがページテーブルを異なる方法で実装するため、異なる動作をします。それがすべてです。階層には常に同じ固定深さがあります（時々構成可能）。ディスクからブロックを読み取るのは遅いですが、ページテーブルには重要ではありません。したがって、デザインの問題は完全に異なります。