「iノードサイズ」と「iノードあたりのバイト数」の違いは何ですか
以下の情報はmanページから取られたものですが、inodeあたりのバイト数とInodeサイズの違いを知りたいのですが？
-i bytes-per-inode
バイト/ inode比を指定します。 mke2fsは、ディスク上のinodeバイトあたりのスペースのバイトごとにiノードを作成します。 iノードあたりのバイト数の比率が大きいほど、作成されるiノードの数は少なくなります。この値は通常、ファイルシステムのブロックサイズより小さくすべきではありません。それは、作成されるiノードが多すぎるためです。作成後にファイルシステムのiノードの数を拡張することはできないので注意してください。このパラメータの値。
-I inode-size
各iノードのサイズをバイト単位で指定します。mke2fsはデフォルトで256バイトのiノードを作成します。 2.6.10以降のカーネルおよび一部の以前のベンダーのカーネルでは、128バイトを超えるiノードを使用して拡張属性を格納し、パフォーマンスを向上させることができます.inodeサイズの値は、128以上の2の累乗でなければなりません。 -size iノードテーブルが消費する領域が増えると、ファイルシステムの使用可能な領域が減少し、パフォーマンスに悪影響を与える可能性があります。古いiノードに格納されている拡張属性は、古いカーネルでは表示されず、そのようなファイルシステムは2.4カーネルではマウントできません。ファイルシステムの作成後にこの値を変更することはできません。
さて、最初に、iノードとは何ですか？ Unixの世界では、iノードは一種のファイルエントリです。ディレクトリ内のファイル名は、iノードへの単なるラベル（リンク！）です。 iノードは複数の場所（ハードリンク！）で参照できます。
-iノードあたりのバイト数（別名inode_ratio）
不明な理由により、このパラメータはinode_per-inodeと記載されることもあり、inode_ratioと記載されることもあります。ドキュメントによると、これはbytes/inode ratioです。ほとんどの人間は、どちらかと言うと理解が深まります（私の英語は失礼します）。
- ストレージのXバイトごとに1つのiノード（Xはiノードあたりのバイト数）。
- 適合可能な最小平均ファイルサイズ。
式（mke2fsソースコード から取得）：
inode_count = (blocks_count * blocksize) / inode_ratio
または簡略化することもできます（「パーティションサイズ」がblocks_count * blocksizeにほぼ等しいと仮定して、割り当てを確認していません）：
inode_count = (partition_size_in_bytes) / inode_ratio
注1：FS作成時間（mkfs -N ...））で固定数のiノードを指定した場合でも、値は比率に変換されるため、拡張するにつれてより多くのiノードに適合できます。ファイルシステムのサイズ。
注2：この比率を調整する場合は、使用する予定のものよりもかなり多くのiノードを割り当てるようにしてください...ファイルシステムを再フォーマットする必要はありません。
-i inode-size
これは、ファイルシステムが持つ可能性のある各iノードにファイルシステムが割り当てる/予約するバイト数です。スペースは、iノードの属性を格納するために使用されます（読み取り Intro to Inodes ）。 Ext3では、デフォルトのサイズは128でした。Ext4では、デフォルトのサイズは256です（extra_isizeを格納し、インライン拡張属性にスペースを提供するため）。読み取り Linux：なぜiノードサイズを変更するのですか？
注：Xバイトのdisjkspaceは、割り当てられている各iノードに割り当てられており、空きか使用かにかかわらず、X = inode-sizeです。
iノードあたりのバイト数は、そのファイルシステムに対して作成されるiノードの数を決定します。 inode-sizeは、それらの各iノードの大きさを決定します。
小さなファイル（および/または多くのディレクトリ）のlotsをファイルシステムに配置する場合は、多くのiノードが必要です。
私の知る限り、実際に必要なのは、ファイルに 拡張属性 を格納する場合に、デフォルトのサイズである256バイトより大きいiノードだけです。 psusiはコメントでそれが正しくないと言っています。
非常に大まかなファイルシステムの回路図：
|_|__inodes__|_______________________DATA_________________________________|
- inode-ratio/bytes-per-inode = [〜＃〜] data [〜＃〜]エリアのiノードの量
- inode-size = inodes領域の各iノードのサイズ
私は本当にsjasの答えが好きでした、それは違いの本質を与えます。
これは私自身の拡張であり（コメントや投票はできないため、このstackexchangeから始めます）、データ量の中で決定を下す必要があるユーザーが理解できる非技術的な用語でバランスの取れた方法で自分自身に答えを求めていましたセットアップ、しかし必ずしも実装の背後にあるすべての詳細を知っているわけではありません。
ペルソナ/オブジェクト：-ストレージデバイス内のデータのボリューム-ボリューム内のファイル-ストレージデバイス、フォーマットされ、バイトのブロックとそのアドレスを提供します-ストレージ内のファイルの場所
アクション：ストレージ内のオペレーティングシステムによるファイルとフォルダの作成/削除/名前変更、ファイルの読み取り/書き込み/移動、権限の変更など。
Nバイトのサイズのファイルは、「チャンク」（ブロック）で作成する必要があります。理論的には、ファイルを1バイトのシーケンスとして管理できる（論理的にはできる）と考えることができますが、スペースでファイルを管理するために必要なのは、特定のインデックス（ファイルのプロパティ（名前など）と各ファイルの開始位置）だけです。ストレージ。ただし、「バス」と「ブロック」を使用してハードウェアを設計する方法とパフォーマンスの考慮により、これらの「チャンク」は特定のサイズであり、メディアのブロックサイズの倍数（512バイト、4096バイトなど）であり、ファイルの場所と、チャンクを見つけてメモリにロードする必要がある場合にチャンクがどのように結合されるかについて次のレイヤーに通知するinodesレイヤーによって管理されます。
1枚の大きな巻物（ボリューム）があり、複数ページのドキュメントを格納するために（文字または情報の）ページで構成されるドキュメントの情報ストレージを設計する必要がある場合、（ドキュメントを検索するための）インデックスが必要です。ページ（ページのいくつかの単純な位置を含む）。 Unixの照合メカニズム（inodes）および実際のページへの切り取り。 inode-sizeはインデックスエントリのサイズ（多かれ少なかれ）で、iノードあたりのバイト数はページサイズです。
問題の2つの設定を変更した場合の影響：
changin inode-size-通常、変更する必要はありません。デフォルトに固執します（ディスカッションへの以前の回答で投稿されたリンクによる）
inodeあたりのバイト数-ボリューム内に作成できるファイルの最大数に影響します（おそらくパフォーマンスと未使用バイトの「無駄」）
ロール紙の例に戻ると、特定のサイズのドキュメント（ファイル）をこのようなシステム（またはさまざまなサイズの多くのドキュメント）に書き込んで保存する必要があることを想像してください。 「定義と柔軟性はありませんが、同じドキュメントは多くのページを必要とする可能性があります。「システム」ページサイズが非常に大きく、ドキュメントサイズが小さい場合、空白があり、小さなファイルを1ページに収めることで大量の紙が無駄になる可能性があります。ページサイズが大きい場合-ドキュメントに使用する必要があるページは少なくなりますが、最後に使用したページに多くの「無駄な空白スペース」が存在する可能性があります。したがって、すべては、使用されるファイルのサイズとその数に依存します。他の考慮事項は、多くのページのドキュメントを見つけて持ってくる速度です。
それが理にかなっているといいのですが（私にとってはそうです）、extデザインやmkfsオプションの一部を深刻に乱用した場合はコメントしてください。