大規模なインデックスノードにはどのような利点がありますか？ (外線4)

メタデータが多いファイルが多い場合は、より大きなinodeが便利です。クラシックメタデータ（権限、タイムスタンプなど）を収容できる最小のinodeサイズ複数のアドレスブロック通常のファイルまたは短いシンボリックリンクのターゲットです。より大きなインデックスノード貯えることができる拡張属性例えばアクセス制御リストそしてSELinux コンテキスト。拡張属性を収容するのに十分な領域が十分にない場合は、別のブロックに保存する必要があるため、ファイルを開くか、メタデータを読み取るのが遅くなります。

したがって、多数のinodeを保持する場合は、より大きなinodeサイズを使用する必要があります。拡張属性たとえば、複雑なACLまたはSELinuxを使用している場合です。 SELinuxは大きなinodeを作る主な動機です。

inodeのサイズが大きくなると、ディスク使用量が増えるのではなく、非常に大きなファイル/ディレクトリのパフォーマンスが向上する可能性があります（小さいファイルではパフォーマンスが低下する可能性があります）。

inodeの使用量が高すぎると思われる場合は、inodeあたりのバイト比率を詳しく見てください。さまざまなStackExchangeサイトに関連するQ&Aがたくさんあります。

ディスク使用量20％、inode使用量15％も悪くありません。 20％ディスク使用量と100％inode使用量が問題になる可能性があります。問題は、100％ディスク使用量の前に100％inode使用量に達したかどうかです。これは、より多くのインデックスノードが必要なときです。

これは、ファイルシステムの使用方法によって大きく異なります。たとえば、写真やビデオ、または同じサイズの同じファイルのみを保持するパーティションの場合は、心配する必要はありません。

使用法がランダムで、後でいくつかのカーネルソースtarballをインポートできる場合は、現在の割合が維持されない可能性があります。

パフォーマンスの面では、一般的な状況では違いを感じることはなく、年中無休で動作するデータベースなど、限界を超えるアプリケーションがない限り、小さな最適化でも成果を上げます。

各ファイルは少なくとも1つのinodeを消費し、ファイルが十分に大きい場合はより多くのinodeを消費します。理論的には、パーティションが多数の大容量ファイルで構成されている場合は、少ないinodeが必要です。 inodeの数が少ないということは、データディスク容量が多いことを意味します。特定のアプリケーションはデータベースのパーティション化で、データベースはほとんどのデータをいくつかの大容量ファイル（Oracle、MySQL、innodbなど）に保存します。 「bigalloc」と言うと、「big」に/etc/mke2fs.conf設定されているようなCentOS7のプリセットの1つを意味すると仮定しますか？わかりませんが、これはデフォルトで「inodeあたりのバイト数」パラメータのパラメータのようです。これらの仮定が正しい場合は、コピーの形式を再指定する必要があります。inode_ratio32768mke2fs-i

inodeあたりのバイト比率が高いほど、生成されるinodeの数が減ります。この値は通常、ファイルシステムのブロックサイズより小さくしてはいけません。これは、利用可能なものよりも多くのinodeが生成されるためです。ファイルシステムが作成された後は、この比率を変更することはできません。注意して、このパラメータの正しい値を決定してください。ファイルシステムのサイズを変更すると、この割合を維持するためにinodeの数が変更されます。