私はsjaの答えが本当に好きでした、それは違いの本質を与えます。
これは私自身の拡張です（このスタック交換から始めてコメントしたり投票したりすることはできません）ので、データ量の間に決定を下す必要があるユーザーが理解できる非技術用語でバランスのとれた方法で自分自身に答えを求めましたセットアップが実装の背後にあるすべての詳細を必ずしも知っているわけではありません。
ペルソナ/オブジェクト：-ストレージデバイス内のデータのボリューム-ボリューム内のファイル-ストレージデバイス。フォーマットされ、バイトブロックとそのアドレスを提供します-ストレージ内のファイルの場所
アクション：ストレージ内のオペレーティングシステムによるファイルとフォルダーの作成/削除/名前変更、ファイルの読み取り/書き込み/移動、権限の変更など。
Nバイトのサイズのファイルを「チャンク」（ブロック）で作成する必要があります。理論的には、ファイルは単一バイトのシーケンスとして管理できると考えることができますが（論理的には）、スペース内のファイルを管理するために必要なのは、ファイルのプロパティ（名前など）と各ファイルの開始位置を示す指定されたインデックスだけですストレージ。ただし、「バス」と「ブロック」を使用したハードウェアの設計方法と、これらの「チャンク」は特定のサイズであり、メディアのブロックサイズの倍数（512バイト、4096バイトなど）であり、 iノードレイヤーによって管理されます。iノードレイヤーは、ファイルの場所と、チャンクを見つけてメモリにロードする必要がある場合に、チャンクがどのように連結されるかを次のレイヤーに伝えます。
1つの大きな巻物（ボリューム）があり、複数ページのドキュメントを保存するためのページ（文字または情報のビット）で構成されるドキュメントの情報ストレージを設計する必要がある場合、必要なのは（ドキュメントを検索するための）インデックス、ページ（ページのいくつかの単純な位置）。Unixの照合メカニズム（inode）および実際のページ分割。inode-sizeはインデックスエントリサイズ（多かれ少なかれ）bytes-in-inodeはページサイズです。
問題の2つの設定を変更した場合の影響：
changin inode-size-通常、変更する必要はありません。デフォルトのままにしてください（ディスカッションへの以前の回答で投稿されたリンクによる）
バイトあたりのバイト数-ボリューム内で作成できるファイルの最大数に影響します（未使用バイトのパフォーマンスと「浪費」の可能性があります）
ペーパーロールの例えに戻る：特定のサイズのドキュメント（またはファイル）をそのようなシステム（またはさまざまなサイズの多くのドキュメント）に書き込み、保存しなければならないことを想像してください。 「システム」のページサイズが非常に大きく、ドキュメントサイズが小さい場合、1つのページに空白を入れて小さなファイルを収めることにより、大量の紙が無駄になる可能性があります。ページサイズが大きい場合-ドキュメントに使用する必要があるページは少なくなりますが、最後に使用したページに多くの「無駄な空白」が存在する可能性があります。そのため、使用されるファイルのサイズと数に依存します。もう1つの考慮事項は、多くのページのドキュメントを検索して持ってくる速度です。
それが理にかなっていることを望み（私にとってはそうです）、extデザインまたはmkfsオプションの一部を真剣に悪用した場合はコメントしてください。