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

1. 2013年の記事にエラーがあります。
2. LWNにエラーがありますか？確かですか？
3. 「バックグラウンド」書き込みストレージによって生成されたI / Oデバイスの長いキュー
4. 「I/Oダーティスロットリングなし」の制限は何ですか？
5. 「USB Stall」の問題に関する実際の報告
6. 誤ったダスト制限の計算 [2014]
7. 大きなページ割り当てブロックIO [2011]
8. 「ダーティーページがLRUの終わりに達しました」？ [2013年以前]

1. 2013 年の記事にエラーがあります。

「USBフラッシュドライブの停止」という記事は非常に誤解を招く印象を与えます。これは、元のレポートとさまざまな答えを誤って表現した。

Artemがキャッシュされた書き込みをUSBスティックにフラッシュすると、Artemはシステム停止を報告しません。彼のオリジナルレポート「sync」コマンドの実行に「数十分」かかることがあると文句を言います。この違いは次のとおりです。リヌス・トバルズの回答:

実際、コピーは通常のUSBキーを持ってそこに書き込もうとするのと同じくらい簡単です。私はちょうどランダムなISOイメージで作業を行いましたが、これは苦痛でした。バックグラウンドで他のほとんどのタスクを実行するのは痛いことではありませんが、「同期」されたタスク（そしてスクリプトで発生するタスク）を実行すると、タスクは中断されます。数分。

2.LWNにエラーがありますか？確かですか？

ジョン・コベット15年の経験を持ち、毎週Linuxカーネル開発について報告しています。私はこの記事が少なくともそうすると予想した。閉鎖ある意味では正しく理解してください。だから私はこれら2つの異なる記録を処理して、彼らが同意したり同意しない詳細を見つけたいと思います。

私はすべて読んだオリジナルディスカッション、lore.kernel.orgのアーカイブを使用します。メッセージがとても明確だと思います。

私はこの記事が議論を誤解したと100％確信しています。記事の下のコメントには少なくとも2人の読者が自分の言葉で誤った主張を繰り返したが、これを訂正する人は誰もいなかった。この記事は、3番目の段落で混乱を続けます。

これらのデータはすべてI / Oキューをブロックし、潜在的に他のタスクを遅らせます。そして誰かが電話する限り同期（）、キュー全体が書き込まれるまで、ジョブは中断されます。

Linusは「ただ悲鳴を上げて止まった」と言いますが、これは混乱する可能性があります。 「Thing」は「何でもせよsync」という意味です。しかし、Corbettは、「それ」が「システム全体」を意味するように書いています。

Linusによると、これは実際の問題です。しかし、それはほとんどの「物事」に当てはまります。いいえシステム全体の sync() 操作を呼び出します。 [1]

Corbettがこれを「システム全体」と混同するのはなぜですか？私は多くの問題が発生し、しばらくしてそれらをすべて分離するのは難しいと思います:-). LWNはデバイス固有（およびプロセス固有）ダーティ制限の開発を説明していますが、一般的にそのような詳細についてはあまり書かれているようではありません。多くのドキュメントでは、グローバルダーティ制限設定のみを説明しています。

3. 「バックグラウンド」書き込みストレージによって生成されたI/Oデバイスの長いキュー

Artem 公開セカンドレポートスレッドでは、「サーバーがほぼ停止し、他のIO要求を完了するのに時間がかかります」

2番目のレポートは、USBスティックがかかっているという主張と一致しません。 10GBファイルを作成した後に発生します。内部ディスク。これは別の質問です。

レポートでは、ダーティ制限を変更してこの問題を改善できるかどうかを確認していません。最近、これらの事例が分析された。プライマリディスクのI / Oキューが詰まっていると、深刻な問題が発生します。要求に応じてプログラムコードをロードし、write（）+ fsync（）を使用して文書やアプリケーションデータを保存するなど、頻繁に使用されるディスクで長い遅延が発生する可能性があります。

迷惑なバックグラウンド書き込みの保存を減らします。——LWN.net、2016

メモリマネージコードが一連のダーティデータを書き込むことを決定すると、その結果、ブロックサブシステムにI / O要求が送信されます。要求はI / Oスケジューラに多少時間がかかることがありますが、最終的にターゲットデバイスのドライバに転送されます。

問題は、書き込むダーティデータが多いと、デバイスに待機している要求の数が数千に達する可能性があることです。合理的に高速なドライブでも、あまりにも多くの要求を処理するのに時間がかかることがあります。他のアクティビティ（Webブラウザでリンククリックやアプリケーションを実行するなど）が同じ機器でI / O要求を生成すると、これらの要求は長いキューの後ろに待機し、その要求には使用できません。しばらくご奉仕ください。複数の同時要求が生成される場合（たとえば、新しく起動されたアプリケーションによって生成されたページエラー）、各要求はこの長いキューを順番に通過する必要があります。すべてが停止したように見える瞬間です。

[...]

ほとんどのブロックドライバは内部的に独自のキューも保持します。これらの低レベルのキューは、要求が到着したときにI / Oスケジューラ（存在する場合）の制御を受け取らなくなるため、特に問題になる可能性があります。

これを改善するためにパッチをマージしました。2016年末（Linux 4.10）。このコードを「書き込み保存制限」またはWBTと呼びます。オンラインで検索してみると、wbt_lat_usecこれについてもっと話が出ました。 （元の文書はこれについて書いていますが、wb_lat_usec古いです。）CFQまたはBFQ I / Oスケジューラには書き込み保存制限は適用されません。 CFQは、Linux v4.20より前のデフォルトのカーネルビルドを含むデフォルトのI / Oスケジューラとして広く使用されていました。 CFQはカーネルv5.0から削除されました。。

問題（およびプロトタイプソリューション）を説明するためのテストに進みます。SSD（NVMeのように見える）と「通常のハードドライブハードドライブは、「大規模なバーストIOを持つより深いキュー深度デバイスほど悪くありません。」

キュー内の要求が「何千」であるかはわかりませんが、少なくとも何百もの要求をキューに入れることができるNVMeデバイスがあります。ほとんどのSATAハードドライブは32個の要求をキューに入れることができます（「NCQ」）。もちろん、ハードドライブは各要求を完了するのに時間がかかります。

4. 「I/Oダーティスロットリングなし」の制限は何ですか？

「I/Oダーティスロットリングなし」は、かなり複雑なエンジニアリングシステムです。それも時間が経つにつれて適応になった。きっとあって今もそうだ一部このコード内の制限。

LWN記事、コード/パッチノート、およびスライドショー詳細なデモンストレーションに見られるように、多数のシナリオが考慮されている。これには、悪名高いスローUSBスティックと高速ホストドライブが含まれます。テストケースには、「1000個の同時dds」（つまりシーケンシャルビルダー）というフレーズが含まれています。

これまでダーティ制限コードの制限を実証して再現する方法がわかりません。

私はダーティ制限コードの範囲外の問題に対する修正のいくつかの説明を見ました。私が見つけた最新の修正は2014年にありました。次のセクションを参照してください。 LWNで扱うトピックの中で、私たちは次のことを学びました。

過去のいくつかのリリースでは、このような問題は、多くのダーティページ/不十分な書き込み保存を見るのに疲れ、IOが完了するのを待つ回収の問題が原因で発生しました。

[...] systemtapスクリプトはこのタイプの領域をキャプチャし、修正されたと思います。

メルゴーマ​​ンも説明するいくつかの「未解決の問題」があります。

しかし、まだ問題があります。すべてのダーティページが遅いデバイスによってバックアップされている場合、ダーティの制限により、最終的にダーティページのバランスが崩れます[...]

この記事は、LWNの説明をほぼ裏付ける報告されたディスカッションスレッドで私が見つけることができる唯一のものです。これが何を意味するのか理解できたらと思います。または、これを説明する方法と、ArtemとLinusが実行したテストで重要な問題ではないように見えるのはなぜですか？

5. 「Uディスクスタック」の問題に関する実際のレポート

ArtemとLinuxの両方がシステム全体に影響を与える「USBスティック停止」を報告していませんが、他の場所でこの問題に関するいくつかのレポートを見つけることができます。これには、最後に知られている修正から最近数年間のレポートが含まれます。

違いが何なのかわかりません。おそらくテスト条件がある点で異なる場合があり、2013年以降カーネルに新しい問題がある可能性があります。

• https://utcc.utoronto.ca/~cks/space/blog/linux/USBDrivesKillMyPerformance/https://utcc.utoronto.ca/~cks/space/blog/linux/FishingUSBDriveResponsiveness[2017]
• ファイルをペンドライブにコピーするとコンピュータがフリーズするのはなぜですか？[2014年1月]
• 外部ディスクで過度の読み取り/書き込み操作を実行すると、システムが遅延します。[2018]
• 過度のディスクI / Oを実行すると、Linux GUIが応答しなくなります。何を調整する必要がありますか？[2019]

6. 汚染基準計算エラー [2014]

2014年1月に興味深い修正がありました（カーネルv3.14に適用されます）。質問では、デフォルトの制限がメモリの20％に設定されていると述べました。実際にダーティページキャッシュに使用できるメモリの20％に設定されています。たとえば、カーネルはTCP / IPネットワークソケットから送信されたデータをバッファリングします。ソケットバッファを削除したり、ダーティページキャッシュに置き換えることはできません :-)。

問題は、カーネルがダーティページキャッシュをサポートするためにデータを交換できるように交換可能メモリを計算することです。理論的には可能ですが、カーネルはスワッピングを避け、ページキャッシュを削除することを強く好みます。この問題は、遅いUSBスティックへの書き込み操作が含まれ、これがシステム全体が停止することを指摘するテストとして説明されています。 :-).

バラより回答：[パッチ0/2] mm：大規模な匿名およびダーティキャッシュのリサイクル一時停止を減らします。

回避策は、dirty_ratioこれをファイルキャッシュの一部としてのみ処理することです。

この問題を経験したカーネル開発者によると、「トリガー条件は、高い匿名メモリ使用量、多くのバッファリングされたIO、スワップ構成など、かなり合理的なものに見え、実際にこのようなことが発生する可能性が高い」と述べた。これが理由を説明できます。一部2013年以前のユーザーレポートです。

7. IO時の大型ページ割り当てのブロック[2011]

もう一つの質問は次のとおりです。巨大なページ、遅いドライバー、長い待ち時間（LWN.net、2011年11月）。これで、大きなページの問題は次のとおりです。安定。

そして記事に記載されている内容に関係なく、私の考えではほとんどの最新のLinux PCは、大容量ページを実際には使用しません。。 Debian 10からは変更されることがあります。しかし、Debian 10は可能な限り巨大なページを割り当て始めますが、私にとっては明らかです。遅延を起こさずにdefrag、他の設定を「常に」に変更しない限り。

8.「ダーティーページがLRUの終わりに達しました」[2013年以前]

私はこれを調べていませんが、興味深いものを見つけました。

モーガン2011：同期圧縮書き込みによる新しいUSB関連の遅延。過去にはダーティページがLRUの終わりに達することが最大の問題でした。そしてreclaimで書かれています。。

モーガン2013：この一般的なワークスペースは、LRUの終わりに達するダーティページなどの問題を処理します。(CPU使用率が高すぎます)

これが2つの異なる「LRUの終わりに達する」問題である場合、最初の問題はおそらく本当に悪いように聞こえます。ダーティページが最も最近使用されたページになると、ダーティページの書き込みが完了するまでメモリ割り当ての試行が遅れるように聞こえます。

それが何を意味していても、彼は今問題が解決したと言います。

[1] 1つの例外：しばらくDebianパッケージマネージャはdpkgパフォーマンスを向上させるためにsync（）を使用しました。これは、sync（）が長時間かかる可能性がある正確な問題のために削除されました。彼らはLinuxで使用されている方法に切り替えましたsync_file_range()。バラよりUbuntuのバグ＃624877、コメント62件。

この質問の一部に答える前に、以下は重複する必要があります。

私はArtemの2つのレポートを「I / Oダーティスロットリングなし」コードと一致すると解釈できると思います。

ダーティ調整コードの目的は、各サポートデバイスが「他のデバイスと比較して現在の平均書き込み速度に基づいて」「総後書きキャッシュ」を公平に共有できるようにすることです。フレーズは文書から出てきた。/システム/クラス/bdi/.[2]

最も簡単な場合は、1つのサポートデバイスのみが作成されます。この場合、デバイスの公正なシェアは100％です。 write() 呼び出しは、書込みストレージキャッシュ全体を制御し、「設定ポイント」に保つために調整されます。

dirty_background_ratio書き込みは、バックグラウンド書き込みが開始される時点と後書きキャッシュの厳格な制限dirty_ratioの間の途中で調整され始めます。デフォルトでは、これはそれぞれ使用可能なメモリの10％と20％です。

たとえば、プライマリディスクには最大15％のデータしか書き込めません。保持しているRAMの量によっては、ギガバイトのキャッシュされた書き込みがある可能性があります。この時点で、write（）呼び出しは書き込みの保存速度に合わせて調整され始めますが、これは問題ではありません。中断の問題は、read（）およびfsync（）呼び出しに関連すると予想されます。この呼び出しは、関連していない多くのIOの後ろに閉じ込められます。これは、「書き込み保存制限」コードが解決する特定の問題です。一部の WBT パッチの提出には、これに起因する恐ろしい遅延を示す問題の説明が含まれています。

同様に、USBスティックに記録すると、最大15％まで完全に埋めることができます。 USBへの追加書き込み（）が制限されます。ただし、基本ディスクは公平な配布を使用しません。デフォルトのファイルシステムでwrite（）呼び出しを開始すると、調整されていないか、少なくとも遅延時間がはるかに短くなります。私の考えでは、USB write（）は両方の作者のバランスをとるためにさらに制限されると思います。

フル書き込みストレージキャッシュが一時的に設定値を超えて上昇する可能性があると予想されます。少し難しい場合は、完全な書き込みストレージキャッシュの厳しい制限に達する可能性があります。ハード制限は、デフォルトで使用可能なメモリの20％です。設定オプションはdirty_ratio/ですdirty_bytes。おそらく、デバイスの速度が遅く（おそらくランダムI / Oパターンが原因で）、ダーティスロットルがすぐに速度の変化を認識しないため、この問題が発生する可能性があります。

[2] この記事では、次のことができることを提案します。手動特定のパーティション/ファイルシステムで使用できる後書きキャッシュの割合を制限します。この設定を/sys/class/bdi/*/max_ratio「認識」といいます。制限しようとしているデバイスが現在書き込んでいる唯一のデバイスである場合、制限は大きな影響を与えません。」。