/ tmpの下に約30Mのファイルを誤って作成したバグのあるプログラムを作成しました。 (このバグは数週間前に発生し、1秒あたり2つのサブディレクトリを作成していました。)/ tmpの名前を/ tmp2に変更できたので、ファイルを削除する必要があります。システムはFreeBSD 10、ルートファイルシステムはzfsです。
その間、ミラー内のドライブの1つが故障し、交換しました。ドライブには2つの120GB SSDディスクがあります。
ここに質問があります:ハードドライブの交換とアレイ全体の再同期化には1時間もかかりませんでした。ファイル/ tmp2の削除は別の話です。ファイルを削除する別のプログラムを作成しましたが、1秒あたり30〜70のサブディレクトリしか削除できません。すべてのファイルを削除するには2〜4日かかります。
アレイ全体の再同期に1時間かかりますが、ディスクからの削除には4日かかる可能性はありますか?なぜそれほどパフォーマンスが悪いのですか? 1秒あたり70回の削除は、パフォーマンスが非常に悪いようです。
/ tmp2のiノードを手動で削除することもできますが、これではスペースが解放されません。
これはzfs、またはハードドライブの問題でしょうか。
ZFSでの削除はコストがかかります。ファイルシステムで重複排除を有効にしている場合はさらにそうなります(重複排除されたファイルの逆参照はコストがかかるため)。スナップショットも問題を複雑にする可能性があります。
含まれているデータの代わりに/tmp
ディレクトリを削除した方がよい場合があります。
/tmp
がZFSファイルシステムの場合は、それを削除して、もう一度作成します。
アレイ全体の再同期に1時間かかりますが、ディスクからの削除には4日かかる可能性はありますか?
オフィスビルを考えてみましょう。
すべてのフロアのすべてのオフィスからすべてのコンピュータと家具および備品を削除すると、long時間がかかりますが、別のクライアントがすぐにオフィスを使用できるようになります。
RDXで建物全体を解体することは全体より迅速ですが、次のクライアントはかなり場所がどれほど起草的であるかについて不平を言う可能性があります。
ここでは多くのことが起こっています。
まず、最新のディスクテクノロジーはすべて、バルク転送用に最適化されています。 100MBのデータを移動する必要がある場合は、1つの連続したブロック内にあると、場所全体に分散するのではなく、はるかに速く処理されます。 SSDはここで多くのことを助けますが、連続したブロック内のデータを好みます。
次に、ディスク操作に関する限り、再同期化はかなり最適です。 1つのディスクから大規模な連続したデータのチャンクを読み取り、それに対していくつかの高速CPU演算を実行してから、それを別の大きな連続したチャンクで別のディスクに書き換えます。途中で電源が切れても大したことはありません。チェックサムが不正なデータは無視して、通常どおり続行します。
第三に、ファイルの削除は本当に遅いです。 ZFSは特に悪いですが、実際にはすべてのファイルシステムの削除に時間がかかります。彼らは、ディスク上の多数の異なるデータのチャンクを変更し、それを正しく時間調整する(つまり、待機する)必要があります。これにより、電源障害が発生した場合にファイルシステムが損傷することはありません。
アレイ全体の再同期に1時間かかりますが、ディスクからの削除には4日かかる可能性はありますか?
再同期化はディスクが本当に速いものであり、削除はディスクが遅いものです。 1メガバイトのディスクあたり、ほんの少しの再同期を行うだけで済みます。削除する必要があるそのスペースに千のファイルがあるかもしれません。
1秒あたり70回の削除は非常に非常に悪いパフォーマンスのようです
場合によります。私はこれに驚かないでしょう。使用しているSSDのタイプについては言及していません。最新のIntelおよびSamsung SSDは、この種の操作(読み取り、変更、書き込み)にかなり優れており、パフォーマンスが向上します。安価な/古いSSD(Corsairなど)は遅くなります。ここでは、1秒あたりのI/O操作の数(IOPS)が決定要素です。
ZFS is特に削除に時間がかかります。通常、削除はバックグラウンドで実行されるため、遅延は発生しません。あなたがそれらの膨大な数をしている場合、それはそれを隠すことはできず、あなたを遅らせる必要があります。
付録:削除が遅いのはなぜですか?
イアン・ハウソンは、なぜ遅いのかについてよく答えています。
並行してファイルを削除すると、削除により速度が向上する場合があります。これは、同じブロックを使用する可能性があるため、同じブロックの再書き込みを何度も節約できます。
だから試してください:
find /tmp -print0 | parallel -j100 -0 -n100 rm
1秒あたりの削除数が70を超えているかどうかを確認します。
大量のファイルを削除することは、本当に速い操作ではありません。
anyファイルシステム上のファイルを削除するには、ファイルインデックスを読み取り、インデックス内のファイルエントリを削除(または削除済みとしてマーク)し、ファイルに関連付けられている他のメタデータを削除して、マークを付ける必要があります。未使用としてファイルに割り当てられたスペース。これは、削除するファイルごとに個別に行う必要があります。つまり、大量のファイルを削除するには、大量の小さなI/Oが必要になります。電源障害が発生した場合にデータの整合性を保証する方法でこれを行うと、オーバーヘッドがさらに増加します。
ZFSで発生する特殊性がなくても、通常、3,000万のファイルを削除すると、1億を超える個別のI/O操作が発生します。これはwill高速SSDでも長時間かかります。他の人が述べたように、ZFSの設計はこの問題をさらに悪化させます。
アレイ全体の再同期に1時間かかりますが、ディスクからの削除には4日かかる可能性はありますか?
これは、2つの操作がファイルシステムスタックの異なるレイヤーで機能するために可能です。再同期は低レベルで実行でき、実際には個々のファイルを調べる必要がないため、一度に大量のデータをコピーします。
なぜそれほどパフォーマンスが悪いのですか? 1秒あたり70回の削除は、パフォーマンスが非常に悪いようです。
それはたくさんの簿記をしなければなりません...
/ tmp2のiノードを手動で削除することもできますが、これではスペースが解放されません。
ZFSについては知りませんが、それから自動的に回復できる場合は、結局、バックグラウンドですでに実行しているのと同じ操作を実行する可能性があります。
これはzfs、またはハードドライブの問題でしょうか。
しますzfs scrub
何でも言って?
考えを逆にすれば、とても簡単です。
2番目のドライブを取得します(これは既に持っているようです)。
ドライブAからドライブBに、/ tmpディレクトリを除くすべてをrsyncでコピーします。 Rsyncはブロックコピーよりも遅くなります。
ドライブBを新しいブートボリュームとして使用して再起動します。
ドライブAを再フォーマットします。
これにより、ドライブが最適化され、新しいディレクトリが提供されます(細かいですが、SSDではデフラグはそれほど重要ではありませんが、ファイルの線形化は何の害にもなりません)。