私は2013年にMel Gormanが送った次の電子メールを理解したいと思います。
https://lore.kernel.org/lkml/[Eメール保護]/
しかし、まだ問題があります。すべてのダーティページが遅いデバイスによってバックアップされていても、ダーティの制限により、最終的にダーティページのバランスが崩れます。 [...]意識的でも無意識的でも、私のデスクトップアプリケーションは通常、これらの問題に苦しんでいません。 [...]USBスティックが接続されているときに書き込みが多い作業を無意識に避けている可能性があります。
次のアプローチをお勧めします。ここはいいえまだ実装されておらず、Linux 5.1にあります。
私はまだ私たちが「書き換えたデータのN秒以上を台無しにする必要はありません」という原則に基づいて、bdiあたりの書き込み保存推定値を使用する必要があると思います。書き込みストレージの速度はさまざまな理由で（さまざまなIOソース、ランダム、シーケンシャルなど）さまざまであるため、実装するのはそれほど簡単ではありません。したがって、ある時点で私たちは目標ウィンドウ内にあると思いますが、完全に間違っていると思います。ダーティ比率は確実に保証され、ダーティライトストレージの見積もりは最善の努力であり、場合によっては間違っている可能性があります。
電子メールに記載されているカーネルコードの「未解決の問題」とは何ですか？ Gormanはなぜ既存のコードが停滞すると予想するのですか？
たとえば、最新のPCが一度に5〜10秒以上完全に停止できることを知っていますか？または、開いているウィンドウが一時停止しているように見えますか（続行カーソルを移動してウィンドウを移動できます）。
メールに間違っていることが知られている部分がありますか？
現在、Linuxカーネルにまだ同じ問題がありますか？
私は非常に似た症状の報告を見たことがあります。クリス・シベンマン（Chris Siebenmann）、2017年。
Mel Gormanの電子メールはアーカイブされた議論の一部です。 LWN.netは、この議論について「有害なUSBスティック停止の問題」と書いています。 単にその記事をまねるのは避けてください。これについては後述する。
Test（「何を試してみましたか？」）
私はカーネルを実行します5.1.6-200.fc29.x86_64。 8G Imation USBドライブがあります。 dd if=/dev/zero of=/var/run/media/alan/imation/test bs=1M status=progress約4MiB/sに収束しました。これは私のメインHDDが達成できるよりも約25倍低いです。現在実行すると、grep -E 'Dirty|Writeback' /proc/meminfo特定の時間に約1GiBのキャッシュされた書き込みに収束します。 8GiBの物理RAMがあります。
（Writeback一度に1つまたは2つのMiBのみが表示されます。ダーティレベルは異なる場合があります。以前は、MemTotal（物理RAMなど）のおおよその割合に設定されていました。現在、ダーティレベルはおおよその割合に設定されています。メモリ使用可能）。
USB書き込み中はシステムが応答し続けます。ウィンドウを移動でき、Webブラウザを引き続き使用できます。
USB書き込みの前と途中で、基本HDDで次のレイテンシテストを実行しました。どちらの場合も同じ時間がかかります：約3〜4秒：
mkdir "$HOME"/tmp
cd "$HOME"/tmp
time bash -c "for (( i=0; i < 100; i++ )); do dd if=/dev/zero bs=16k count=1 of=latencytest status=none; sync latencytest; mv latencytest latencytest2; done"
「有害なUSBスティック停止の問題」 - ？
異常にLWNの場合は十分注意して読んでいません。この問題に関するLWNの記事は、2つの異なる問題を統合しています。以下のリンクからこの主張を長く引用してください。読者の疲労を最小限に抑えるために、以下から関連情報を選択しました。
2013年に「USBフラッシュドライブの停止」の問題が発生したのはなぜですか？既存の「I / Oダーティスロットリングなし」コードがこの問題を解決できないのはなぜですか？
アーカイブされた電子メールでは、その数の「ダーティ」（未記録）ページキャッシュが蓄積され、数秒間続く一時停止について説明します。しかし、具体的な内容については少し混乱しています。
これ元の苦情非常に明確です。 Linus Torvaldsは、より具体的な例を挙げて、この苦情を繰り返します。たとえば、任意の1GBファイルをlinux.isoマウントされたUSBフラッシュドライブにドラッグアンドドロップします。ドライブが10MB / sを書き込むことができるとします。time syncファイルシステムにフラッシュキャッシュ書き込みを実行し、100秒かかることを確認しました。書き込みキャッシュが大きすぎるような気がします！
この結果は、RAMが8GB以上かカーネルが64ビットかによって異なります。書き込みキャッシュはRAMの20％に制限されています。劇的な部分は、32ビットカーネルを比較すると、制限がRAMの最初の1GBに基づいてのみ計算されることです。したがって、sync64ビットカーネルに切り替えると、その部分で8倍（または16倍または...）の待ち時間が表示されることがあります。私はこれにショックを受け、欲求不満を感じることを理解することができます:-).
ㅏ第二の苦情発売にもなりました。以下は「失速の近く」シナリオです。メインシステムディスクただ。
2番目のケースのメカニズムはより複雑です。プライマリディスクとプライマリディスクのカーネルIOスケジューラ内の要求キューを入力します。 20秒以上の「ダーティ」キャッシュを許可しない場合でも、問題が発生する可能性があります。 2つの質問の間にはいくつかの重複がありますが。
2番目のケースと同様の問題を見つけるのははるかに簡単に見えます。システムの停止の観点からは、/homeファイルシステムへの書き込みを続けるのははるかに危険に見えます（ここでは、Ctrl + Alt + F6を使用してテキストVTに切り替えることを防止または遅延することが含まれます）。/私は最近これを見ました。最近：「仮想マシンイメージを複製するたびに、システムの応答速度が非常に遅くなります。」