ZFSから1,000万以上のファイルを効果的に削除する

/ tmpの下に約30Mのファイルを誤って作成したバグのあるプログラムを作成しました。（このバグは数週間前に導入され、1秒あたり2つのサブディレクトリが作成されていました。）/ tmpの名前を/ tmp2に変更できたので、ファイルを削除する必要があります。システムはFreeBSD 10で、ルートファイルシステムはzfsです。

一方、ミラー内のドライブの1つが故障したため、交換しました。ドライブには2つの120GB SSDディスクがあります。

問題は、ハードドライブの交換とアレイ全体の再同期化に1時間もかからなかったことです。ファイル/ tmp2の削除もまた別の話です。ファイルを削除する別のプログラムを作成しましたが、1秒あたり30〜70個のサブディレクトリしか削除できません。すべてのファイルを削除するには2〜4日かかります。

アレイ全体の再同期化に1時間かかるのに、ディスクから削除するのに4日間かかることはどのように可能ですか？なぜこんなにパフォーマンスが悪いのですか？70削除/秒は非常にパフォーマンスが悪いようです。

/ tmp2のinodeを手動で削除することもできますが、それでもスペースが解放されませんよね？

これはzfsの問題なのか、ハードドライブの問題なのか

ZFSでの削除は高価です。ファイルシステムで重複排除を有効にしている場合はさらにそうです（重複排除されたファイルの参照解除はコストがかかるため）。スナップショットも問題を複雑にする可能性があります。

/tmp含まれているデータではなく、ディレクトリを削除した方がよい場合があります。

/tmpがZFSファイルシステムである場合、それを削除して再度作成します。

アレイ全体の再同期化に1時間かかるのに、ディスクから削除するのに4日間かかることはどのように可能ですか？

オフィスビルを考えてみましょう。

すべてのフロア上のすべての事業所からのコンピュータおよび家具や固定具のすべてを削除すると、かかる長い時間が、しかし、別のクライアントですぐに使えるオフィスを離れます。

RDXで建物全体を解体することで全体の多くより速く、しかし、次のクライアントがあり、非常に可能性が吹きさらしの場所がどのように文句を言います。

ここでは多くのことが行われています。

まず、最新のディスクテクノロジーはすべてバルク転送用に最適化されています。100MBのデータを移動する必要がある場合、それらが場所に散らばるのではなく、1つの連続したブロックにあると、はるかに高速に移動します。ここではSSDが大いに役立ちますが、連続ブロックのデータを好みます。

第二に、ディスク操作に関する限り、再同期は非常に最適です。1つのディスクから大量の連続したデータチャンクを読み取り、その上でいくつかの高速CPU操作を実行し、別の大きな連続したチャンクで別のディスクに書き換えます。電源が途中で故障した場合、大したことはありません。チェックサムの悪いデータは無視して、通常どおり続行します。

第三に、ファイルの削除は本当に遅いです。ZFSは特に悪いですが、実際にはすべてのファイルシステムの削除に時間がかかります。ディスク上の多数の異なるデータチャンクを変更し、電源が切れた場合にファイルシステムが破損しないように、正確に時間を計る（待機する）必要があります。

アレイ全体の再同期化に1時間かかるのに、ディスクから削除するのに4日間かかることはどのように可能ですか？

再同期はディスクが本当に速いものであり、削除はディスクが遅いものです。ディスクのメガバイトあたり、あなたはほんの少しの再同期を行うだけです。そのスペースに削除する必要があるファイルが1000個ある場合があります。

70削除/秒は非常にパフォーマンスが悪いようです

場合によります。これには驚かないでしょう。使用しているSSDの種類については言及していません。最新のIntelおよびSamsung SSDは、この種の操作（読み取り-変更-書き込み）で非常に優れており、パフォーマンスが向上します。より安い/古いSSD（Corsairなど）は遅くなります。ここでは、1秒あたりのI / O操作数（IOPS）が決定要因です。

ZFS は、物を削除するのが特に遅いです。通常、バックグラウンドで削除が実行されるため、遅延は発生しません。あなたがそれらの膨大な数をしている場合、それを隠すことができず、あなたを遅らせる必要があります。

付録：削除が遅いのはなぜですか？

• ファイルを削除するには、いくつかの手順が必要です。ファイルのメタデータは「削除済み」としてマークする必要があり、最終的にはスペースを再利用できるように再利用する必要があります。ZFSは「ログ構造化ファイルシステム」であり、ものを作成するだけで削除しない場合に最高のパフォーマンスを発揮します。ログ構造とは、何かを削除するとログにギャップがあるため、ギャップを埋めるために他のデータを再配置（デフラグ）する必要があることを意味します。これはユーザーには見えませんが、一般に低速です。
• 変更は、途中で電源が落ちた場合にファイルシステムの一貫性が保たれるように行う必要があります。多くの場合、これは、データが実際にメディア上にあることをディスクが確認するまで待機することを意味します。SSDの場合、長時間（数百ミリ秒）かかります。これの最終的な効果は、より多くのブックキーピング（つまり、ディスクI / O操作）があることです。
• 変更はすべて小規模です。フラッシュブロック全体（または磁気ディスクのシリンダー）の読み取り、書き込み、および消去の代わりに、1つを少し変更する必要があります。これを行うには、ハードウェアがブロックまたはシリンダー全体を読み取り、メモリ内で変更してから、メディアに再度書き込む必要があります。これには長い時間がかかります。

アレイ全体の再同期化に1時間かかるのに、ディスクから削除するのに4日間かかることはどのように可能ですか？

2つの操作がファイルシステムスタックの異なるレイヤーで機能するため、可能です。再同期化は低レベルで実行でき、実際には個々のファイルを見る必要がなく、一度に大量のデータをコピーします。

なぜこんなにパフォーマンスが悪いのですか？70削除/秒は非常にパフォーマンスが悪いようです。

たくさんの簿記をする必要があります...

/ tmp2のinodeを手動で削除することもできますが、それでもスペースが解放されませんよね？

ZFSについては知りませんが、それから自動的に回復できる場合、最終的には、バックグラウンドで既に実行しているのと同じ操作を実行する可能性があります。

これはzfsの問題なのか、ハードドライブの問題なのか

ないzfs scrub何も言いますか？

大量のファイルを削除することは、決して高速な操作ではありません。

上のファイルを削除するためには任意のファイルシステムを、あなたは（削除済みとしてまたはマーク）、ファイルのインデックスを読んで削除する必要がインデックス内のファイルエントリ、ファイルに関連付けられた他のメタデータを削除し、そのファイルに割り当てられたスペースをマーク未使用。これは、削除するファイルごとに個別に行う必要があります。つまり、大量のファイルを削除するには、大量の小さなI / Oが必要になります。電源障害が発生した場合にデータの整合性を確保する方法でこれを行うと、さらにオーバーヘッドが追加されます。

ZFSが導入する特異性がなくても、3000万のファイルを削除すると、通常は1億を超えるI / O操作が必要になります。これは、高速のSSDでも長時間かかります。他の人が述べたように、ZFSの設計はこの問題をさらに悪化させます。

Ian Howsonは、なぜ遅いのかについて良い答えを与えています。

並行してファイルを削除すると、削除が同じブロックを使用し、同じブロックの書き換えを何度も保存できるため、速度が向上する場合があります。

だから試してください：

find /tmp -print0 | parallel -j100 -0 -n100 rm

1秒あたり70回の削除よりもパフォーマンスが良いかどうかを確認します。

あなたの思考を逆にする場合は非常に簡単です。

1. 2番目のドライブを入手します（すでにこれを持っているようです）

2. / tmpディレクトリを除き、rsyncを使用してドライブAからドライブBにすべてをコピーします。Rsyncはブロックコピーよりも遅くなります。

3. ドライブBを新しいブートボリュームとして使用して再起動します

4. ドライブAを再フォーマットします。

これにより、ドライブが最適化され、新しいディレクトリが作成されます（SSDではデフラグはそれほど重要ではありませんが、ファイルを線形化しても問題はありません）

ソートされていないリストに3000万のエントリがあります。削除するエントリのリストをスキャンして、削除します。これで、ソートされていないリストには29,999,999のエントリしかありません。すべてが/ tmpにある場合、なぜ再起動しないのですか？

コメントの情報を反映するように編集：問題のステートメント：/ tmpにある30M +の誤って作成されたファイルのすべてではなく、ほとんどを削除するのに時間がかかります。
問題1）/ tmpから大量の不要なファイルを削除する最良の方法。
問題2）ファイルの削除が非常に遅い理由を理解する。

解決策1）-ほとんどの* nixディストリビューションでは、ブート時に/ tmpが空にリセットされます。ただし、FreeBSDはそれらの1つではありません。
ステップ1-興味深いファイルを別の場所にコピーします。
ステップ2-ルートとして

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

ステップ3-再起動。
ステップ4-clear_tmp_enableを「いいえ」に戻します。FreeBSDの
ZFSには、「すべてのファイルをスキャンし、対応するすべてのメタデータを更新する必要がないため、データセットにあるすべてのファイルを削除するよりもデータセットを破棄する方がはるかに速い」という機能があるため、不要なファイルはなくなりました。 」したがって、起動時に行う必要があるのは、/ tmpデータセットのメタデータをリセットすることだけです。これは非常に迅速です。

解決策2）なぜそんなに遅いのですか？ZFSは、一定時間のディレクトリアクセスなどの機能を含む素晴らしいファイルシステムです。自分が何をしているのか知っていればこれはうまくいきますが、証拠はOPがZFSの専門家ではないことを示唆しています。OPは、ファイルを削除する方法を示していませんが、推測では、「find regex -exec rm {} \;」のバリエーションを使用したと思います。これは小さな数でもうまく機能しますが、3つのシリアル操作が行われるため、スケーリングされません1）利用可能なファイルのリストを取得します（ハッシュ順に3,000万ファイルを返します）、2）削除する次のファイルを選択するために正規表現を使用します、3 ）3,000万のリストからそのファイルを見つけて削除するようOSに指示します。でも、場合 ZFSはメモリからのリストを返し、もし 「検索」はそれをキャッシュします、正規表現はまだリストから処理される次のファイルを識別し、その変更を反映するためにメタデータを更新し、リストが更新されて再度処理されないようにOSに指示する必要があります。