外部ディスクで過度の読み取り/書き込み操作を実行すると、システムが遅延します。

この問題をどのように解決できますか？

ディスクイメージに書き込むときにddwithを使用しますoflag=direct。 O_DIRECT 書き込みは、ページキャッシュを介したデータの書き込みを防止します。oflag=direct良いパフォーマンスを得るには、より大きなブロックサイズが必要です。例は次のとおりです。

dd if=/dev/usbdisk1 of=/dev/usbdisk2 oflag=direct bs=32M status=progress

注：時には他のプログラムからパイプを望むことがあります（たとえばgunzip、良いパフォーマンスはiflag=fullblock他のコマンドによって異なり、それを介してddパイプされます）。ここに答えの完全な例があります。ddパイプラインのgunzipが遅くなるのはなぜですか？

（別の解決策はoflag=sync代わりにを使用することですoflag=direct。これは、多数のビルドを構築しないことで達成できます。書かれていないキャッシュされたページ）。

私が理解したところによると、各ディスクには独自のIOキューがありますが、ここで何が起こっているのでしょうか。

彼らは。ただし、作成されたデータは最初にシステムページキャッシュ（RAM）に保存され、次にIOがキューに格納されます。

---

編集する：

この回答が承認されたので、もう一度テストしてoflag=direct「システムがクロールされたばかりです」という問題が解決したとします。途方もない。

iflag=direct最も安全なオプションはそれも追加することです。このオプションがない場合は dd、読むデータはシステムページを介してキャッシュされます。私はあなたが私に言わずにこのオプションを追加しなかったと仮定します。これはあなたの特定の質問のヒントです。

ページキャッシュを介してあまりにも多くのデータを読み取っていることは明らかです。できるシステムのパフォーマンスに影響を与えます。ページキャッシュを介してプッシュされるデータの総量は、システムRAMよりも数倍大きいです。 :-).読み取りパターンに応じて、カーネルはスペースを確保するためにキャッシュされた他のデータの削除（または交換）を開始することを決定できます。

カーネルには確かなビジョンはありません。キャッシュから削除されたデータを使用する必要がある場合は、ディスク/ SSDから再ロードする必要があります。証拠〜らしいこれはあなたの問題ではないと教えてください。

ダーティページキャッシュの制限

ただし、お客様の問題は、以下に関連する可能性が高くなります。書くデータはページを介してキャッシュされます。 「ダーティ」ページキャッシュとも呼ばれる未記録キャッシュは制限されています。たとえば、ダーティページキャッシュ全体がRAMの20％に制限されているとします。 （想像を助けるための嘘であり、真実は台無しに書かれている）ここ）。

コマンドddが最大ダーティページキャッシュを埋めると、一部のデータが書き込まれるまで強制的に「ブロック」（待機）されます。

ただし、同時に書きたい他のプログラムもブロックされます（O_DIRECTを使用しない限り）。これにより、多くのデスクトッププログラムがログファイルに書き込もうとすると動作が停止することがあります。異なるデバイスに書いている場合も同様です。

全体ダーティ制限の名前dirty_ratioはまたはですdirty_bytes。しかし、全体の話ははるかに複雑です。異なるデバイスのダーティキャッシュ間にはある程度の調停が必要です。初期しきい値を設定し、あるデバイスで使用されるダーティキャッシュの最大割合を制限します。しかし、これがどれだけうまく機能するかを正確に理解するのは難しいです。

「複数のUSBディスク」のイメージングに問題があると言われているようです。たとえば、デバイス固有のしきい値は、いずれかのディスクに書き込もうとすると正しく機能しますが、複数のディスクに同時に書き込むと競合が発生する可能性があります。しかし、それは単なる考えであり、何が起こるのかわかりません。

関連:

一部のユーザーは、低速のUSBドライブに書き込むときにシステム全体の遅延を観察し、ダーティ制限全体を下げると遅延を防ぐのに役立ちます。私はこれの良い説明がわかりません。

2013年に「USBフラッシュドライブの停止」の問題が発生したのはなぜですか？既存の「I / Oダーティスロットリングなし」コードがこの問題を解決できないのはなぜですか？

「書き込み保存制限」は「USBメモリーカードの停止の問題」の解決策ですか？