読み取りおよび書き込み操作の速度（バイト/秒など）、累積（バイトなど）など、ディスクI / Oを追跡するさまざまな方法に精通していますが、何も知りません（見つかりません）。プロセススペースによって取得されたトレースディスクの数。私はこれがディスクスペースを「確保する」時期/方法を定義する複雑さに関連していると思います。
たとえば、rm fileファイルの内容は「なし」形式で上書きされず、ポインタが消去されるなどの方法です。つまり、基本的にfileディスク容量を確保しますが、ディスク容量を確保する他の方法もたくさんあります。既存のnull以外のオブジェクトに対してfile操作を実行すると、そのecho '' >file内容は消去されます。複数のプロセスで開かれたハードリンクとファイルは、スペースが解放されるタイミング/方法の定義がある程度あいまいであるため、ディスク使用量の追跡をより複雑にすることができます。
ベストアンサー1
「プロセスによって解放されたディスク容量」は非常にあいまいなので、それほど有用な概念ではありません。プロセスAがプロセスBにまだ開いているファイルを削除する場合、Aがファイルを削除するときにスペースを解放したと思いますか（つまり、システムがディスクスペースを確保すると約束しました）、またはBが閉じられたときにスペースを確保したと思います。しますか？ファイル（つまり、システムがディスク容量を確保すると約束した場合）？スペースが実際に解放されましたか？）ファイルに2つのハードリンクがあり、両方のプロセスが同時に1つのハードリンクを削除する場合、解放されたスペースを最初のハードリンクではなく2番目のハードリンクに割り当てることは本当に意味がありますか？プロセスがファイルの一部を上書きする場合、上書きされたデータを解放すると見なされますか？ （ファイルシステムが重複排除を実行すると、答えは変わりますか？）ちょっと待ってください。
定義を選択してそれを追跡するためにカーネルコードをインストルメントすることができますが、これはややランダムな選択であり、実際の使用は限られているため、一般的に使用される機能ではありません。すべての機能には費用がかかります。プログラマーがそれを実装するのにかかる時間、プログラマーが後でそれを維持するのに費やした時間、それによって発生する可能性のあるバグのリスク、メモリーおよびCPUの消費...
既存のデバッグ機能（LinuxのSystemtapなど）を使用して、一般的なシナリオでこれを達成できます（再び特定の定義を選択する）。