一般に、ブロックデバイスドライバはデバイスの正確なサイズを報告し、「利用可能な」すべてのブロックを実際に使用できます。したがって、ファイルシステムはそのデバイスに書き込むことができる量を事前に知っています。ただし、機器を使用したり機器を
使用したりするなど、一部の特殊なケースでは、この声明は間違っています。これらのブロックデバイスは、プライマリストレージ（親FSが不明）がいっぱいになった場合はいつでもエラーを返すことができます。だから私の質問は、この状況で何が起こるのかということです。 EXT4ファイルシステムがモード（デフォルト）でマウントされており、多くの書き込みを行っています。ディスクキャッシュ（ダーティメモリ）も機能しますが、ユーザーがコマンドを実行すると書き込むデータが多くなります。しかし、突然、対応するEXT4ファイルシステムの基本ブロックデバイスは、「残りのスペースがない」という理由ですべての書き込みを拒否し始めます。ファイルシステムの動作は何ですか？エラーを印刷し、すべての書き込みを中断し、データ損失を引き起こす可能性があるモードに切り替えますか？そうでない場合は、スペースを待ってから定期的に書き込みを再試行し、新しい書き込みを拒否しますか？この場合、他のプロセスが大量のRAMを割り当てようとすると、巨大なディスクキャッシュはどうなりますか？ （Linuxではダーティメモリは無料と見なされます。そうですか？）最悪のシナリオを考えると、エラーが発生したときにディスクキャッシュがRAMの大部分を占めた場合（管理者がRAMを高すぎるため）、カーネルがクラッシュまたはロックするになりますか？それとも、メモリを割り当てたいすべてのプロセスを待機/停止するのですか？最後に、異なるファイルシステムが異なる動作をしますか？よろしくお願いします。dm-thindm-vdoENOSPCr/wasyncsyncr/oENOSPCvm.dirty_ratio
答え1
ブロックデバイスが使用可能なデータ容量を過度に使用した場合（たとえば、シンプロビジョニングを使用する場合）、他の理由でより多くの書き込みを許可できない場合（スナップショットがいっぱいになるなど）、書き込みにメッセージを送信する必要があります。この場合、ENOSPCは意味がないため、通常選択されたエラーはEIO（エラー入力/出力）です。
アップデート：LVMには実際に設定可能な動作があります。シンプロビジョニングLV用:
--errorwhenfull n（デフォルト）：OPが考慮するように最大（設定可能）60秒間ブロックし、エラーを発生させます。この60秒以内に自動アクションが実行されない場合、結果は即時エラーと同じです。また、タイムアウトを完全に無効にする場合は、次の点に注意してください。
タイムアウトを無効にすると、システムリソースの枯渇、メモリの枯渇、タスクの中断、およびデッドロックが発生する可能性があります。 （タイムアウトはシステムのすべての仮想プールに適用されます。）
--errorwhenfull y: エラーをすぐに返す
「ユーザー」がファイルシステムの場合、実際のメディアエラーによって引き起こされるようにI / Oエラーに応答します。これはマウントオプションによって異なります（例：外部4可能なオプションはerrors={continue|remount-ro|panic}）です。緊急ではないオプションの1つを選択すると、キャッシュ内のダーティデータがどのようになるのかわかりません。キャッシュに残っているか失われると想像できますが、とにかく失われると仮定する必要があります。
これは重大な結果であるため、これらのディスク容量を積極的に監視し、しきい値に達したときに過度に使用されているスペースがいっぱいにならないように、データを解放するか、実際のスペースを追加する必要があります。スナップショット、特に時間の経過とともにより多くのスペースを使用するシンプロビジョニングされていないスナップショットの場合も同様です。これ以上必要ない場合は削除する必要があります。緊急事態が発生した場合にシンプロビジョニングされたスペースを自動的に増やすオプションもあります（シンプロビジョニングされたレイヤーにスペースを提供するレイヤーがまだより多くのスペースを提供できる場合）。
追加リファレンス：
答え2
ファイルシステム（およびインストールオプションも可能）と基本ストレージによって異なります。
ほとんどの場合、スペースが過剰に割り当てられてブロックデバイスに書き込めない場合は、IOエラーでファイルシステムドライバに即座に伝播されます。 LVMにはこれを遅らせるオプションがありますが（主に自動サイジング機能が開始される時間を提供するため）、デフォルトでは無効になっています。 QEMUには、まれなディスクイメージでこの動作を制御するオプションがありますが、デフォルトではゲストオペレーティングシステムにエラーを伝播します（エラーを無視するか、仮想マシンを一時停止するように設定することもできます）。しかし、他のほとんどのものはファイルシステムドライバに即座にエラーを発生させます。
ここで何が起こるかは、ファイルシステムによって異なります。 ENOSPCではなくEIOですが、ほとんどすべての場合、エラーはユーザースペースに伝播されます（ENOSPCはファイルシステムにスペースが不足していることを意味しますが、ここでは技術的に問題ではなく、通常ファイルシステムも確認できません）。 IO エラーは下位層で発生するため、通常は下位層のスペース不足によるものかどうかはわかりません。デフォルトでは、ext4は他の操作を実行しませんが、マウントオプション（およびで設定したものtune2fs）に応じて読み取り専用で再マウントしたり、カーネルパニックを引き起こしたりできます。 BTRFSは読み取り専用で再マウントされ、一部のマルチデバイス設定ではパフォーマンス低下モードに切り替えることもできます。他のファイルシステムについてはよくわかりません（この場合、XFSは読み取り専用として再マウントされると予想しています）。