EXT4におけるiノード数の増加の欠点
私は現在 backintime を使用してファイルシステムの「スナップショット」を取得しています。これは rsnapshot に似ており、変更されていないファイルへのハードリンクを作成します。最近、EXT4ファイルシステムでiノードが不足しました。 df -hiは、940万のiノードを使用したことを示しています。現在のディレクトリの数にスナップショットの数と現在のファイルの数を掛けた数のおおよそのカウントは、実際には940万のiノードを使用していることを示唆しています。
私が理解しているところによると、EXT4ファイルシステムは約2 ^ 32のiノードをサポートできます。 40億個ほどのiノードすべてを使用するようにパーティションを再フォーマットすることを検討していますが、これが悪い考えだと心配しています。 EXT4ファイルシステムに非常に多くのiノードがあることの欠点は何ですか？このようなアプリケーションのためのファイルシステムのより良い選択はありますか？
それは本当に悪い考えです。各iノードは256バイトを消費します（128として構成できます）。したがって、iノードだけが1TiBのスペースを消費します。
Btrfsなどの他のファイルシステムは、iノードを動的に作成できます。代わりにそれらの1つを使用してください。
私はこれを十分に強調することはできません。大量のiノードを作成しないでください。
最初にfsckランタイムを指数関数的に長くすることができますが、これらの懸念の一部はext4で対処されました。さらに重要なことに、ファイル数を制限する要素はiノードだけではなく、これらのiノードをすべて使用することはおそらく不可能です。これは実際に話すだけではなく、実際には技術的に不可能かもしれません。
Mkfs manページからの抜粋、
-iバイト/ inodeバイト/ inode比を指定します。 mke2fsは、ディスク上のinodeバイトあたりのスペースのバイトごとにiノードを作成します。 iノードあたりのバイト数の比率が大きいほど、作成されるiノードの数は少なくなります。この場合、使用可能な数よりも多くのiノードが作成されるため、この値は通常、ファイルシステムのブロックサイズよりも小さくしないでください。作成後にファイルシステムのiノード数を拡張することはできないため、このパラメーターの正しい値を慎重に決定するように注意してください。
OPの新しいファイルシステムを作成するとき、現実的に言えば、OPはiノードあたりの最大バイト数=ブロックサイズまで数値を計算し始める必要があります...これを後で読むすべての人にとって、OPは非常に珍しいケースを持っています膨大な数のファイル。