23
数百万のファイルがあるディレクトリでのrm
背景:物理サーバー、約2年、3Ware RAIDカードに接続された7200-RPM SATAドライブ、ext3 FSマウントnoatimeおよびdata = ordered、狂気の負荷なし、カーネル2.6.18-92.1.22.el5、稼働時間545日。ディレクトリにはサブディレクトリが含まれておらず、数百万の小さなファイル(〜100バイト)と、いくつかの大きな(数KB)ファイルがあります。 過去数か月の間に少しカッコウしたサーバーがありますが、ファイルが多すぎるためにディレクトリに書き込めなくなったのは先日だけです。具体的には、/ var / log / messagesにこのエラーをスローし始めました。 ext3_dx_add_entry: Directory index full! 問題のディスクには、多くのiノードが残っています。 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda3 60719104 3465660 57253444 6% / したがって、ディレクトリファイル自体に含めることができるエントリの数の制限に達することを意味していると思います。ファイルがいくつになるかはわかりませんが、ご覧のとおり、300万個以上になることはありません。それは良いことではありません、気に!しかし、それは私の質問の一部です:その上限は正確に何ですか?調整可能ですか?私が怒鳴る前に、私はそれを抑えたいです。この巨大なディレクトリはあらゆる種類の問題を引き起こしました。 とにかく、これらすべてのファイルを生成していたコードの問題を追跡し、修正しました。今、私はディレクトリを削除することにこだわっています。 ここにいくつかのオプションがあります: rm -rf (dir) 最初にこれを試しました。目立った影響なしに1日半走った後、私はそれをあきらめて殺した。 ディレクトリでのunlink(2):間違いなく検討に値しますが、質問はunlink(2)で削除するよりもfsckでディレクトリ内のファイルを削除する方が速いかどうかです。つまり、何らかの方法で、これらのiノードを未使用としてマークする必要があります。もちろん、これはfsckに/ lost + found内のファイルにエントリをドロップしないように指示できることを前提としています。そうでなければ、私は問題を動かしただけです。他のすべての懸念に加えて、これについてもう少し読んだ後、おそらく私が見つけることができるunlink(2)バリアントのどれも私がただ単に削除することを許可しないため、いくつかの内部FS関数を呼び出さなければならないでしょうエントリが含まれるディレクトリ。プー。 while [ true ]; do ls -Uf | head …