읽기 및 쓰기 작업의 속도(예: 바이트/초) 및 누적(예: 바이트)을 포함하여 디스크 I/O를 추적하는 다양한 방법에 대해 잘 알고 있지만 어떤 방식으로도 알지 못합니다(찾을 수 없음). 프로세스 공간으로 인해 확보된 추적 디스크의 수입니다. 나는 이것이 디스크 공간을 "확보"하는 시기/방법을 정의하는 복잡성과 관련이 있을 수 있다고 생각합니다.
예를 들어, rm file파일의 내용은 "없음" 형식으로 덮어쓰이지 않고 포인터가 지워지는 등의 방식입니다. 즉, 기본적으로 file디스크 공간을 확보하지만 디스크 공간을 확보하는 다른 방법도 많이 있습니다. 기존의 null이 아닌 개체에 file작업을 수행하면 echo '' >file해당 내용이 지워집니다. 여러 프로세스에서 열린 하드 링크와 파일은 공간이 확보되는 시기/방법에 대한 정의가 어느 정도 모호하므로 디스크 사용량 추적을 더욱 복잡하게 만들 수 있습니다.
답변1
"프로세스에 의해 해제된 디스크 공간"은 매우 모호하기 때문에 그다지 유용한 개념이 아닙니다. 프로세스 A가 프로세스 B에 아직 열려 있는 파일을 삭제하는 경우 A가 파일을 삭제할 때 공간을 확보했다고 생각합니까(즉, 시스템이 디스크 공간을 확보하겠다고 약속했습니다), 아니면 B가 닫힐 때 공간을 확보했다고 생각합니까? 파일(즉, 시스템이 디스크 공간을 확보하겠다고 약속한 경우)? 공간이 실제로 해제되었습니까?) 파일에 두 개의 하드 링크가 있고 두 프로세스가 동시에 하나의 하드 링크를 삭제하는 경우 해제된 공간을 첫 번째 하드 링크가 아닌 두 번째 하드 링크에 할당하는 것이 실제로 의미가 있습니까? 프로세스가 파일의 일부를 덮어쓰는 경우 덮어쓴 데이터를 해제하는 것으로 간주됩니까? (파일 시스템이 중복 제거를 수행하면 대답이 바뀌겠습니까?) 잠깐만요.
정의를 선택하고 이를 추적하기 위해 커널 코드를 계측할 수 있지만 이는 다소 임의적인 선택이고 실제 사용이 제한적이므로 일반적으로 사용되는 기능이 아닙니다. 모든 기능에는 비용이 있습니다. 프로그래머가 이를 구현하는 데 소요되는 시간, 프로그래머가 나중에 이를 유지 관리하는 데 소요되는 시간, 이로 인해 발생할 수 있는 버그의 위험, 메모리 및 CPU 소비...
기존 디버깅 기능(예: Linux의 Systemtap)을 사용하여 일반적인 시나리오에서 이를 달성할 수 있습니다(다시 특정 정의 선택).