- - PR -
UNIXサーバのi-node、リンクカウントの上限について
1
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2009-01-11 01:01
初めて投稿します。宜しくお願い致します。
UNIXサーバのi-node、リンクカウントの上限について質問があります。 業務システムで使用しているディレクトリ(仮にAとします)の直下に約7万個のサブディレクトリがあります。 ディレクトリAの直下には年間5000個程ディレクトリが増えますが、 ディレクトリAの直下に新規のディレクトリが作成できないトラブルが発生しました。 最初はサイズオーバーしたのかと思い調査しましたが、サイズは問題ありませんでした。 次にinode数がカンストしたと疑いましたが、サブディレクトリの直下にはそれぞれ100個程のファイルが格納されており、 ディレクトリA下にあるファイル数は1000万個程で、df -iコマンドで確認できる ディレクトリAを含むファイルシステムのinode数の使用率は50%程でした。 次にディレクトリAをls -lコマンドで確認するとリンクカウンタが2の32乗(約43億)でした。 意図的にlnコマンドでハードリンクをしている事はありませんでした。 試しにディレクトリA直下のサブディレクトリを一つ削除したら、新規のディレクトリが一つ作れましたので、 古いディレクトリをバックアップ後削除して対応しましたが、根本対処にはなりません。 自力で解るだけ調べてみましたが、直接の原因はハードリンク数がカンストしている為だと思います。 しかし、なぜこれほどハードリンクが増えるのでしょうか? サーバに設定ミスがあるのか、それとも他に何か原因があるのか、 どこを調べたらいいのか行き詰ってしまった為、質問致します。 | ||||
|
投稿日時: 2009-01-11 11:40
まずは、OSの種類、バージョン、ファイルシステムの種類が
明記されていないと的確な回答のしようがないと思います。
根本的な原因はこのディレクトリ構成の方針な気がします。 少なくとも、B-Tree系のアルゴリズムを使わないFSでは、 この桁の数のエントリではパフォーマンス的に破綻します。 具体的な解決策ですが、 1. ファイルシステムの種類を(モダンな設計のものに)変える 2. Aとそのサブディレクトリの間にもう一階層ディレクトリを導入する のどちらかが有効なのではないでしょうか。 |
1