私は現在使用していますbackintime私のファイルシステムの「スナップショット」を撮ります。似ているrsnapshotそのうち、変更されていないファイルへのハードリンクが作成されます。最近、私のファイルシステムにinodeが不足していましたEXT4。df -hi940万個のinodeを使用したようです。現在のディレクトリ数にスナップショット数と現在のファイル数を掛けておおよその計算をすると、実際には940万個のinodeを使用していることがわかりました。
私が知っているのは、EXT4ファイルシステムは約2^32個のinodeをサポートすることです。 40億個程度のinodeをすべて使うようにパーティションを再フォーマットすることを考えていますが、残念ながらそれは悪い考えです。ファイルシステムにあまりにも多くのinodeを持つことの欠点は何ですかEXT4？このようなアプリケーションにはより良いファイルシステムオプションがありますか？
答え1
これはとても悪い考えです。各inodeは256バイトを消費します（128バイトで構成可能）。したがって、inodeだけでも1TiBの空間を消費することになります。
他のファイルシステム（例：btrfs）は、inodeを動的に生成できます。代わりに、次のいずれかを使用してください。
答え2
この点はいくら強調しても過度ではありません。多数のinodeを生成しないでください！
まず、fsckこれらの問題のいくつかはext4で解決されましたが、ランタイムは指数関数的に拡張される可能性があります。さらに、inodeだけがファイル数を制限するわけではなく、すべてを使用することは不可能かもしれません。これは実用的であるだけでなく、実際には技術的に不可能です。
mkfsのマニュアルページから抜粋、
-i inodeごとのバイトバイト/inode比を指定します。 mke2fs は、ディスク上の各 inode バイトスペースごとに inode を生成します。 inodeあたりのバイト比率が高いほど、生成されるinodeの数が減ります。この値は通常、ファイルシステムのブロックサイズより小さくしてはいけません。これは、利用可能なものよりも多くのinodeが生成されるためです。ファイルシステムは作成後にinodeの数だけ拡張できないため、注意してこのパラメータの正しい値を決定する必要があります。
OPの新しいファイルシステムを作成するとき、OPは実際にはinodeごとの最大バイト数=ブロックサイズの計算を開始する必要があります。後でこの内容を読むすべての人にとって、OPは非常に珍しい状況にあり、多くの文書があります。