先週、私は(私にとって新しい)問題に直面しました。私はext4(Fedora 15)ファイルシステムを使用しています。サーバーで実行されているアプリケーションが突然停止しました。一見すると問題は見つかりません。
df
50%の空き容量が表示されます。約1時間検索した後、誰かがdf -i
。オプションを使用してinodeの使い方を見つけたフォーラム投稿を見つけました。システムに inode がありません。これは私が認識しない簡単な問題です。このパーティションには320万のインデックスノードしかありません。
今私の質問は:システムにさらにinodeを持たせることができますか?ディスクをフォーマットするときに設定する必要がありますか/設定できますか? 3.2M inodeを使っていくつのファイルを持つことができますか?
答え1
いつも予想していたよりも多くのファイルがあるようです。
inodeテーブルサイズを動的に変更する方法があるかどうかわかりません。申し訳ありませんが、データをバックアップし、新しいファイルシステムを作成してデータを復元する必要があります。
この大きなinodeテーブルを使用して新しいファイルシステムを作成するには、mke2fs(8)の "-N"オプションを使用する必要があります。
inodeの数を見積もるために、最初に「-n」オプションを使用することをお勧めします(ファイルシステムを作成するのではなく、有用な情報を表示します)。次に、必要に応じて「-N」を使用して、特定のinode番号を持つファイルシステムを作成します。
答え2
320万個のinodeを使用すると、合計320万個のファイルとディレクトリを持つことができます(ただし、ファイルへの複数のハードリンクは1つのinodeのみを使用します)。
はい、パーティションにファイルシステムを作成するときに設定できます。オプション-T usage-type
、-N number-of-inodes
またはは-i bytes-per-inode
inodeの数を設定できます。私は通常、ファイルコレクションの合計と同じ出力を比較し、少し-i
余裕を許してからを使用します。du -s
find | wc -l
いいえ。既存のファイルシステムでは変更できません。しかし:
- LVMを実行している場合、またはファイルシステムがSANのLUNにある場合(LUNに直接またはLUNの最後のパーティションに)、パーティションを分割した後にディスクに空き容量がある場合は、パーティションを大きくすることができます。次に、それを使用して
resize2fs
ファイルシステムを拡張します。これにより、追加されたスペースにほぼ比例してより多くのインデックスノードが追加されます。スペースが解放される前にinodeが不足するのを防ぐために、将来の平均ファイルサイズがほぼ同じであるとしますtune2fs -m
。 - 十分なスペースがあり、ファイルシステムをオフラインに切り替えることができる場合は、オフラインに切り替えてより多くのinodeを含む新しいファイルシステムを作成し、すべてのファイルをコピーします。
- ファイルのサブセットだけが多数の inode を使用し、十分な空き容量がある場合は、ファイルシステムのファイルがサポートするループデバイスにファイルシステムを作成し、より多くの inode (およびより小さいブロック) を持つファイルシステムを作成し、問題のあるディレクトリをそのディレクトリに移動します。これはパフォーマンスに影響を与え、メンテナンスの問題を引き起こす可能性がありますが、代替案です。
- もちろん、不要なファイルをたくさん削除できれば役に立ちます。
答え3
別の回避策として、大量のファイルを圧縮されていない(!)tar
アーカイブに圧縮し、ファイルシステムarchivemount
にマウントすることを検討してください。 tarアーカイブはファイルシステムイメージよりも共有に適しており、クラウドや他のストレージにバックアップするときに同様のパフォーマンスを提供します。
コレクションが読み取り専用である必要がある場合はオプションですが、squashfs
カーネルでいくつかのオプションを有効にする必要があり、xz
同じパフォーマンスでtarを使用して圧縮することもできます。
答え4
du -s --inodes * 2>/dev/null |sort -g
出力の最後のディレクトリにcdを試してから繰り返します。
完全な公開:すべてのオペレーティングシステムが--inodes
duコマンドをサポートしているわけではありませんが(私のMac OSではサポートしていません)、多くのLinuxオペレーティングシステムはサポートしています。