十分にテストされていないプログラムが、NFS 共有上に膨大な数のファイルを含むディレクトリを作成しました。これを削除する必要があります。
ls -ald /home/foo
drwxrwxr-x 2 503 503 317582336 Jul 29 11:38 /home/foo
ディレクトリは、netapp タイプのデバイス上の約 600 GB の NFS マウントにあります。実際、そこにいくつのファイルがあるかはわかりませんが、わずか 10 分後に作成された同様のディレクトリには 121,000 個のファイルがあるため、おそらく数百万個はあるでしょう。OS は Linux 2.6 カーネルです。
それとその内容を一覧表示または削除する方法を見つけようとしています。 find /home/foo の結果、約 1 時間後に find が終了し、「./」以外の出力は表示されません。
答え1
(同様のものを検索中に誰かが見つけた場合に備えて、自分の質問に答えます。) ディレクトリには、おそらく 900 万個ものファイルがあります。
残念ながら、アプライアンスなのでサーバーに直接ログインすることはできません。ファイルシステムへのアクセスはエクスポート経由のみです。
rm -rf は機能していないようです。strace で見るとハングしていました。
find は完了せず、エラーなしで終了しました。
ls -1 は完了しないようです。(結果のソートを試みていることに今気付きました。ls -1f は最終的には機能したかもしれません)。
実際に機能したのは、単純な Perl スニペットでした。同じことを実行する C コードでも機能すると思います。
opendir( my $dh, '/home/foo' ) or die $!
while ( my $file = readdir $dh ) {
print "$file\n";
}
答え2
このかなり古いスレッドが Google で見つかったので、いくつかの統計を共有したいと思います。
NFS サーバー上のファイルを削除する 3 つの異なる方法を比較します。
- プレーンrm:
rm dir/* - 探す:
find dir/ -type f -exec rm {} \; - rsync:
tempdir=$( mktemp -d ); \ rsync -a --delete $tempdir/ dir/; \ rmdir $tempdir
これらの方法を比較するために、テストを実行するたびに10000個のファイルを作成しました。
for i in {1..10000} ; do touch $i ; done
プロットの結果は、rsyncがはるかに高速で、findが3つの方法の中で最も遅いことを示しています。
ファイル数が 2 倍になった場合 ( find20000 ファイルでは実行しませんでした) の結果は同じで、10000 ファイルの場合は 3 回の実行、20000 ファイルの場合は 2 回の実行の平均時間が計算されます。
10000 20000
find 28.3 -
rm 12.9 23.9
rsync 6.94 12.2
これらの方法のパフォーマンスが他に何に依存するかを知ることは興味深いことです。
関連する役職このサイトでは、ext3 ファイルシステム上の大量のファイルの削除について説明しています。
答え3
これらのファイルを NFS 経由で削除しないことをお勧めします。ファイル サーバーに直接ログインして、そこでファイルを削除します。これにより、NFS サーバー (およびクライアント) への影響が大幅に軽減されます。
それ以外では、find が完了できない場合は、(MattBianco の説明に従って) find を使用するか、ls -1 | xargs rm -f(そのディレクトリ内から) use を使用します (後者は NFS 経由でも問題なく動作するはずですが、やはりローカルで実行することをお勧めします)。
答え4
これは少し明白なことのように思えますが、次のことを試しましたか:
rm -rf /home/foo/
? それができない場合、正規表現を使用して、渡すのに十分な小さいサブセットを取得する方法はありますか|xargs rm?
ls が失敗した場合は、試してみるecho /home/foo/* | xargs rmと、「行が長すぎます」などのエラーで失敗する可能性があります。ああ、NFS 経由ではなく、サーバー上で直接これを行うことをお勧めします。