2 ^ 32-1 iノードを使用してext4ファイルシステムを作成することには欠点がありますか?
1TBのドライブがあり、その上に8億から15億の小さなファイルを保存したいと思います。最大値は40億と思われるため、fsを作成するときに最大値に設定するだけでよいのか、他の解決策を見つける必要があるのか疑問に思っています。
Stack Overflow および nix&Linux (以下を参照)に関する同様の質問によると、ext4ファイルシステム上のiノードの数を最大にすることは悪い考えです。
別のファイルシステムを使用するか、ディスクを複数のファイルシステムに分割してください。
要約する:
Iノードは256バイトを占有します。 128に設定することもできますが、次の場合でも:
2³² inodes × 256 bytes each = 1 TB
Ext4ファイルシステムを作成するとき、/etc/mke2fs.conf
で定義されているようにusage typeを指定できます:
mkfs.ext4 -T usage-type /dev/something
多くの小さなファイルを保存するには、タイプsmall
を使用できます。
small = {
blocksize = 1024
inode_size = 128
inode_ratio = 4096
}
つまり、ディスクスペース(ファイルシステムのサイズ)の4096バイトごとに、それぞれが128バイトのサイズのiノードが1つ予約されます。したがって、コマンドmkfs.ext4 -T small /dev/something
は、31 GBを占有する1TBファイルシステム上に2億4400万のiノードを作成します。これらの2億4400万個のファイルは、少なくとも250 GB(それぞれ1024バイト以上)を占有します。
小さなフットプリント(128バイト)で10億のiノードを保持するには、iノードだけに128 GBが必要です。可能な最小のブロックサイズ(mk2efsのマンページによると1024)が使用される場合、これらの10億個のファイルは少なくとも1TBを占有します(ただし、iノードの128 GBのために872 GBしか残っていないことに注意してください)。
Ext4の最小ブロックサイズは1024バイトです。したがって、1 TB/1024 = 10億個を超えるファイルを保存することはできず、iノードを増やすことは無意味です。
一般的な経験則として、1つのブロックに複数のファイルを(簡単に)保存できないため、inode_ratio
はblocksize
より小さくしないでください。
ファイルシステムがそのように構成されていれば、ファイルの最初の60バイトをiノードに直接保存することができます。その場合、ファイルは(通常の)ブロックを占有しません。このような インラインデータはこちら を読んでください。ただし、 inodeサイズ も考慮してください。
コメントから &Lの質問 へ:
Inodeが多すぎると、確かに大きなコストがかかり、スペースを占有し、fsckのパフォーマンスは非常に深刻だと信じています。 30秒と2日間のように、実質的に指数関数的な速度低下が発生しています...これはI/Oの制約です。ファイルのリスト、インデックス作成などの速度低下は言うまでもありません.
参照: