나는 "모든 것이 파일이다"라는 말이 완전히 정확하지는 않다는 것을 알고 있지만, 내가 아는 한 각 프로세스는 /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를 사용하여 액세스하는 모든 항목(열기, 읽기, 쓰기, 닫기)을 의미합니다.
이 네 가지 기능은 매우 일반적인 API이며 Unix는 항상 이 API에 다른 모든 것을 집어넣습니다. 문자 장치, 블록 장치 및 명명된 파이프는 모두 동일한 4가지 기본 기능을 통해 액세스되지만 디스크의 파일은 읽고 쓰지 않습니다.
전통적으로 장치 파일에는 경로 조회를 단순하게 유지하기 위해 디스크에 항목이 있지만 이는 파일 시스템에 proc비효율적 sys이므로 사용자 정의 조회도 있고 디스크에 아무 것도 쓰지 않습니다. 파일 시스템도 마찬가지 입니다 tmp. 데이터를 캐시에 보관할 뿐입니다(그리고 범용 스왑으로 교체할 수도 있습니다).
따라서 액세스하지 않아도 오버헤드가 전혀 발생하지 않습니다. 이를 수행할 때 필요한 것은 커널에 dentry, inode 및 파일 구조를 할당하고(파일 설명자를 바인딩하기 위해) 내부 커널 구조에 정보의 형식을 지정하는 것뿐입니다. 전용 API보다 약간 느리지만 커널에 더 많은 진입점을 추가하지 않고 기존 유틸리티를 활용하여 정보를 처리할 수 있습니다.