有害なUSBスティックがかかる問題-LWN.net、2013.
低速のストレージデバイス(USBスティックやメディアプレーヤーなど)をLinuxコンピュータに接続し、大量のデータを書き込みます。システム全体が停止し続けます。、これは数分間続くことができます。
この記事では、カーネルのデフォルト値が簡単に変更されると予測します。 64ビットx86では、後書きキャッシュはデフォルトでシステムRAMの最大20%まで増加できます。 Linusは32ビットx86コードの制限をエミュレートし、すべてのプラットフォームで効果的に最大180MBに制限することをお勧めします。しかし現在、Linux(v4.18)はいいえ推奨される変更が含まれています。 (比較するリヌスのパッチ、到着するv4.18の現在の機能)。
2013年のLWN記事では、この問題を「バッファ拡張問題と同等のストレージ」と呼びました。これで、書き込みストレージ制限(// wbt
)という新しいLinux機能を紹介する2016 LWN記事があります。この記事では、書き込みストレージの制限を「ネットワークスタックで発生した問題を反映するバッファ拡張の問題」を軽減する方法について説明します。これは非常に同様に聞こえます:-)。CONFIG_WBT
wbt_lat_usec
特定のUSBスティック停止の問題は今解決されましたか?
迷惑なバックグラウンド書き込みの保存を減らします。- LWN.net、2016
私たちの多くが経験した経験があります。比較的遅いブロックデバイスに大量のデータを書き込んでから、別の操作を実行しようとします。ほとんどの場合、システムの速度が遅くなったり一時的に停止したり、ほとんどのデータがデバイスに書き込まれるまで操作は再開されません。大容量メモリと低速I / Oデバイスを備えたシステムでは、利用可能な状態に復元するのに時間がかかることがあり、時には数分かかることがあります。 Linuxユーザーはこれらの行動パターンに目を向けますが、長い間頑張っています。これで、新しいパッチセットが状況を改善することができます。
この質問からインスピレーションを得ました。外部ディスクで過度の読み取り/書き込み操作を実行すると、システムが遅延します。
答え1
問題は、「USB Stalling」記事が主張を裏付ける証拠を提供していないことです。 「USBスティック停止」の問題が実際に存在し、常に同様のレポートがいくつか出ています。しかし、LWNの記事で議論されたトピックはそのうちの1つではありません!したがって、この記事を例に挙げることはできません。さらに、それが提供するすべての説明に欠陥があるか、少なくとも不完全である可能性があります。
2013年に「USBフラッシュドライブの停止」の問題が発生したのはなぜですか?既存の「I / Oダーティスロットリングなし」コードがこの問題を解決できないのはなぜですか?
リンクされた回答をまとめると、次のようになります。
linux-kernel doに報告された問題いいえUSBスティックにキャッシュされた書き込みをフラッシュしている間、システム全体がハングすることがわかります。 Artemの初期のレポートでは、Linuxが遅いデバイスで大規模なキャッシュ書き込みを可能にし、完了するために「数十分」かかる可能性があると不平を言いました。
あなたが言ったように、Linusが提案した「修正」はまだ適用されていません。現在のカーネルバージョン(v4.20以下)では、大容量RAMを持つシステムがページキャッシュに大量の書き込みを作成できるため、書き込みに時間がかかることがあります。
カーネルには、すでに「USBスティックの停止」を防ぐように設計されたいくつかのコードがあります。これは「I / Oダーティスロットリングなし」コードです。このコードは2011年のLWNでも説明されています。後書きキャッシュ全体のサイズと write() 呼び出しを制限して、使用される後書きキャッシュの割合を制御します。特定のサポートデバイスの場合。これは、時間の経過とともに継続的に調整される複雑なエンジニアリングシステムです。私はそれにいくつかの制限があると確信しています。今までどんな限界も定量化できませんでした。動作を妨げる問題を解決するために、ダーティ調整コードの外側で様々なバグ修正が行われた。
WBTは提出数を制限します。IOリクエスト個々のデバイスごとに。後書きキャッシュを制限しません。つまり、ダーティです。ページキャッシュ。
Artemは、10GBがサーバーに記録されたという後続のレポートを発表しました。内部ディスクが原因でシステムがハングするか、少なくとも応答が非常に長い間遅れます。 それこれは、WBTが解決しようとしている問題と一致します。
この回答の以前のバージョンで維持された追加のメモ:
WBTで説明するシナリオは、コンピュータに大量のデータを書き込む場合です。基本プログラムのロードなどに基本ディスクを対話的に使用し続けたい場合
対照的に、人々が「USBスティック停止」の問題について話すとき、これは他のディスク/外部USBなどに多くのデータを書き込んだ後、そのディスクに関連しないプログラムで驚くべき遅延を経験することを意味します。例:
「ウィンドウを移動するのと同じくらい簡単なことも気にすることができます...リモートシステムへのSSHセッションが完全に応答するため、CPU負荷ではありません。 」
- https://utcc.utoronto.ca/~cks/space/blog/linux/USBDrivesKillMyPerformance
- https://utcc.utoronto.ca/~cks/space/blog/linux/FixinUSBDriveResponsiveness?showcomments
USBスティック問題に関する2013年メーリングリストスレッド、今後の作業の可能性として、ダーティページキャッシュのデバイス固有の制限について言及しました。。
WBT は CFQ または BFQ IO スケジューラでは使用できません。 DebianとFedoraはデフォルトでCFQを使用しているため、特別な設定がない限り、WBTはUSBスティック(または回転するハードドライブ)には役立ちません。
伝統的に、CFQは回転するハードドライブでうまく機能します。 WBTがどこに行くのかよくわかりません。おそらくWBTの最大の利点は、回転するハードドライブよりも高速ですが、RAMのように処理するには遅すぎるSSDです。
deadline
あるいは、スケジューラを使用してCFQ機能を放棄する必要があるという主張があるかもしれません。 Ubuntuに切り替えるdeadline
バージョン14.04からしかし、CFQに戻ります。バージョン17.04(情熱)。 (CentOS 7.0は古すぎてWBTがないようですが、SATAドライブとdeadline
他のすべてのドライブにCFQを使用すると主張しています。CentOS 7.0もNVMeドライブをサポートしていますが、まったく「スケジューラーのために。)