私は「すべてがファイルです」という言葉が完全に正確ではないことを知っていますが、私が知っている限り、各プロセスは複数の/procファイルを含むディレクトリを取得します。読み取り/書き込み操作は速度の面で大きなボトルネックを引き起こすことが多く、ファイルからファイルに常に読み書きするには処理速度が大幅に遅くなります。
多くのファイルを保存する必要/procが遅くなりますか？そうでなければ、多くのIOを実行する必要がないことは、Linuxの大きな設計上の欠陥ではありませんか？
答え1
ファイルは純粋に動的に生きてい/procて存在します/sys。つまり、何も読まないと、ファイルはまったく存在せず、カーネルはファイルを生成するのに時間がかかりません。
/procそして/sysファイルをAPI呼び出しとして考えることができます。これを実行しないと、カーネルはどのコードも実行しません。
答え2
私はあなたが「すべてがファイルです」を文字通り受け入れていると思います。これが実際に意味するのは、「すべてがアクセス可能」です。良いこれはファイルです。」
他の答えでは、実際には次のように言うこともできます。何もない実際には/procディスクにファイルとして存在します。/procファイルシステムはディスク容量をまったく占有しないため、メンテナンスにI / Oは必要ありません。ファイルシステムをマウント解除し、ディスク使用量の数値を見ると/proc確認できます。 *
代わりに、プログラムがアクセスしようとするとその内容が動的に生成されます。たとえば、と入力すると、カーネルがプロセステーブルから現在のプロセスIDのリストを取得し、通常のディレクトリ名であるかのようにls /procプログラムに送信することが実際に発生します。ls各「ディレクトリ」の内容と/proc。
*通常のシステムでは、/procファイルシステムが使用されている可能性があり、これによりマウント解除ができない可能性があります。したがって、このテストを実際に実行するにはシングルユーザーモードで起動する必要がありますが、成功は保証されません。
答え3
ファイルについて考えるもう一つの方法/procは、「すべてがファイル」ですが、すべてのファイルがディスクに格納されているバイトではないことです。
ファイルの場合、/procディスクストアからバイトを取得するのではなく、カーネルが実行されているプロセスの状態に応じて必要なバイトを動的に生成することで読み取りが満たされます。
同様に、ファイル書き込み/proc（許可されている場合）は、ディスク上のバイトではなくカーネルと対話します。
答え4
ここでは「文書」という言葉があまりにも多く使われていました。物理ディスクに保存されているファイルを意味することもできますが、この場合はファイルAPIを使用してアクセスするすべての項目（開く、読み取り、書き込み、閉じる）を意味します。
この4つの機能は非常に一般的なAPIであり、Unixは常にこのAPIに他のすべてを組み込みます。文字デバイス、ブロックデバイス、および名前付きパイプはすべて同じ4つの基本機能を介してアクセスされますが、ディスク上のファイルは読み書きできません。
伝統的に、デバイスファイルにはパスルックアップを単純にするためにディスクにエントリがありますが、これはファイルシステムに対してproc非効率的sysであるため、カスタムルックアップもあり、ディスクには何も書きません。ファイルシステムも同様ですtmp。データをキャッシュに保存するだけです（そしてユニバーサルスワップに置き換えることもできます）。
したがって、アクセスしなくてもオーバーヘッドは発生しません。これを行うときに必要なのは、カーネルにdentry、inode、およびファイル構造を割り当てて（ファイル記述子をバインドするため）、内部カーネル構造に情報をフォーマットすることだけです。専用APIよりも少し遅いですが、カーネルに追加のエントリポイントを追加することなく、既存のユーティリティを利用して情報を処理できます。