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

Question

問題は、「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負荷ではありません。」

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ドライブをサポートしていますが、まったく「スケジューラーのために。）

Answer 1