왜 open()
와 close()
유닉스 파일 시스템 디자인에 존재 하는가?
OS가 처음 감지 read()
하거나 write()
호출되어 open()
정상적으로 수행되는 작업을 수행 할 수 없었 습니까?
답변
데니스 리치에 언급 «유닉스 시간 공유 시스템의 진화» 그 open
와 close
함께 read
, write
그리고 creat
처음부터 시스템에 존재했다.
나는없이 시스템을 생각 open
하고 close
상상할 수없는 것, 그러나 나는 디자인을 복잡하게 할 생각합니다. 일반적으로 하나의 호출이 아닌 여러 번의 읽기 및 쓰기 호출을 원하며 이는 UNIX가 시작된 RAM이 매우 제한적인 이전 컴퓨터에서 특히 그렇습니다. 현재 파일 위치를 유지하는 핸들이 있으면이를 단순화합니다. 만약 read
나write
핸들을 반환해야했는데 핸들과 자신의 반환 상태 인 쌍을 반환해야했습니다. 쌍의 핸들 부분은 다른 모든 호출에 쓸모가 없으므로 배열이 어색합니다. 커서 상태를 커널에 남겨두면 버퍼링뿐만 아니라 효율성을 향상시킬 수 있습니다. 경로 조회와 관련된 비용도 있습니다. 손잡이를 사용하면 한 번만 지불하면됩니다. 또한 UNIX 월드 뷰의 일부 파일에는 파일 시스템 경로가 없거나 파일 시스템 경로가 없습니다 /proc/self/fd
.
답변
그런 다음 모든 read
및 write
호출은 각 작업에 대해이 정보를 전달해야합니다.
- 파일의 이름
- 파일의 권한
- 발신자가 추가하거나 생성하는지 여부
- 호출자가 파일 작업을 완료 했는지 여부 (사용되지 않는 읽기 버퍼를 버리고 쓰기 버퍼가 실제로 쓰기를 완료했는지 확인)
당신이 독립적 인 생각하든 전화를 open
, read
, write
및 close
I / O의 단일 목적과 간단합니다 메시지가 당신의 디자인 철학을 기반으로합니다. 유닉스 개발자는 모든 작업을 수행하는 단일 작업 (또는 프로그램)이 아닌 여러 가지 방식으로 결합 할 수있는 간단한 작업 및 프로그램을 사용하기로 결정했습니다.
답변
파일 핸들의 개념은 파일 시스템의 일부가 아닌 것을 포함하여 “모든 것이 파일”인 UNIX의 디자인 선택 때문에 중요합니다. 테이프 드라이브, 키보드 및 스크린 (또는 텔레타이프), 펀치 카드 / 테이프 리더, 직렬 연결, 네트워크 연결 및 (주요 UNIX 발명)와 같은 “파이프”라는 다른 프로그램에 직접 연결합니다.
당신이 좋아하는 간단한 표준 UNIX 유틸리티의 많은 보면 grep
특히 원래 버전에서, 당신은 그들이 호출을 포함하지 않는 것을 알 수 있습니다 open()
및 close()
하지만 단지 read
와 write
. 파일 핸들은 셸에 의해 프로그램 외부 에서 설정되고 시작될 때 전달됩니다. 따라서 프로그램은 파일 또는 다른 프로그램에 쓰는지 신경 쓸 필요가 없습니다.
뿐만 아니라 open
, 파일 설명을 얻을 수있는 다른 방법은 socket
, listen
, pipe
, dup
, 및 파이프를 통해 파일 기술자를 보내는 매우 히스 로빈슨 메커니즘 : https://stackoverflow.com/questions/28003921/sending-file-descriptor-by-linux -소켓
편집 : 간접 계층과 이것이 O_APPEND가 현명하게 작동하게하는 방법을 설명하는 강의 노트 . inode 데이터를 메모리에 유지하면 시스템이 다음 쓰기 작업을 위해 다시 가져와야 할 필요가 없습니다.
답변
open ()과 close ()는 각각 핸들을 만들고 파괴하기 때문에 대답은 ‘아니요’입니다. 예상치 못한 파싱을 통해 파일에 쓰는 다른 호출자 (예를 들어)가 예기치 않게 떠날 수 있기 때문에 특정 액세스 수준의 유일한 발신자임을 보장하려는 경우가 있습니다 (실제로 항상). 알 수없는 상태의 응용 프로그램 또는 라이브 록 또는 교착 상태 (예 : 식당 철학자 보조)로 연결됩니다.
이러한 고려 사항이 없어도 고려해야 할 성능 관련 사항이 있습니다. close ()는 파일 시스템이 (적절한 경우 또는 호출 한 경우) 사용중인 버퍼를 비우도록합니다. 인 메모리 스트림에 대한 여러 번의 연속 편집은 파일 시스템에 대한 본질적으로 관련이없는 읽기 / 쓰기-수정 사이클보다 훨씬 효율적입니다. 로컬 스토리지에서도 메모리는 일반적으로 대량 스토리지보다 훨씬 빠릅니다.
답변
Open ()은 사용중인 파일을 잠그는 방법을 제공합니다. 파일이 자동으로 열리고, 읽히고 쓴 다음 OS에 의해 다시 닫히면 다른 응용 프로그램이 작업간에 해당 파일을 변경하는 것을 막을 수있는 것은 없습니다.
간단하게 관리 할 수 있지만 (많은 시스템에서 비 독점 파일 액세스를 지원) 대부분의 응용 프로그램은 열려있는 파일이 변경되지 않는다고 가정합니다.
답변
파일의 경로는 동일하게 유지된다고 가정하는 동안 이동 될 수 있습니다.
답변
파일 시스템을 읽고 쓰는 작업에는 다양한 버퍼링 체계, OS 하우스 키핑, 저수준 디스크 관리 및 기타 여러 가지 잠재적 인 작업 이 포함될 수 있습니다. 따라서 이러한 유형의 후드 활동에 대한 조치 open()
및 close()
설정이 수행됩니다. 파일 시스템의 다른 구현은 필요에 따라 고도로 사용자 정의 될 수 있으며 여전히 호출 프로그램에 투명하게 남아 있습니다.
OS에 개 / 폐가없는 경우 with read
또는를 사용 write
하면 해당 파일 작업은 매번 초기화, 버퍼 플러시 / 관리 등을 수행해야합니다. 반복적 인 읽기 및 쓰기를 위해 많은 오버 헤드가 발생합니다.