프로세스를 분기하면 하위 프로세스는 상위 프로세스의 파일 설명자를 상속합니다. 내가 아는 한, 이런 일이 발생하면 하위 프로세스는 동일한 열린 파일 설명을 가리키는 각 파일 설명자 테이블의 포인터와 함께 상위 프로세스의 파일 설명자 테이블 복사본을 받습니다. 이것은 다음과 같은 파일 테이블과 동일합니까?http://en.wikipedia.org/wiki/File_descriptor, 또는 다른 것?
답변1
파일 설명자 → 열린 파일 설명 → 디렉토리 항목
dup open cp
프로세스에서 열린 파일부터 파일 내용까지 여러 수준의 간접 참조가 있습니다. 구현 측면에서 이러한 수준은 일반적으로 다음 수준을 가리키는 커널의 데이터 구조로 변환됩니다. 간단한 구현에 대해 설명하겠습니다. 실제 구현은 더 복잡할 수 있습니다.
프로세스에서 열린 파일은 음수가 아닌 작은 정수인 파일 설명자에 의해 지정됩니다. 숫자 0, 1, 2는 일반적인 의미를 갖습니다. 프로세스는 0(표준 입력)에서 일반 입력을 읽고, 1(표준 출력)에 일반 출력을 쓰고, 2(표준 오류)에 오류 메시지를 써야 합니다. 이는 단지 관례일 뿐입니다. 커널은 신경 쓰지 않습니다. 커널은 각 프로세스에 대해 열린 파일 설명자 테이블을 유지하여 이러한 작은 정수를파일 설명자 구조. Linux 커널에서 이 구조는 다음과 같습니다.struct fd.
파일 설명자 구조에는 다음을 가리키는 포인터가 포함되어 있습니다.파일 설명 열기. 프로세스 호출과 같이 여러 프로세스에서 동일한 열린 파일 설명을 가리키는 여러 파일 설명자가 있을 수 있습니다.dup친구와 함께 또는 프로세스 포크 후에. 파일 설명자(다른 프로세스에서도)가 open동일한 원래(또는 유사한) 시스템 호출로 인해 발생한 경우 동일한 열린 파일 설명을 공유합니다. 열린 파일 설명에는 모드(읽기 전용 대 읽기-쓰기, 추가 등), 파일 내 위치 등을 포함하여 파일이 열린 방법에 대한 정보가 포함됩니다. Linux에서 열린 파일 설명 구조는 다음과 같습니다.struct file.
열린 파일 설명은 파일 API 수준에 있습니다. 다음 레벨은파일 시스템API. 차이점은 파일 API가 익명 파이프 및 소켓과 같이 파일 시스템 트리에 존재하지 않는 파일을 다룬다는 것입니다. 파일이 디렉토리 트리의 파일인 경우 열린 파일 설명에는 다음을 가리키는 포인터가 포함됩니다.디렉토리 항목. 동일한 파일을 open여러 번 편집하는 경우 동일한 디렉토리 항목을 가리키는 열린 파일 설명이 여러 개 있을 수 있습니다. 디렉토리 항목에는 상위 디렉토리에 대한 포인터와 파일 위치에 대한 정보를 포함하여 파일 내용에 대한 정보가 포함됩니다. Linux 커널에서 디렉토리 항목은 두 가지 수준으로 나뉩니다.struct inode파일 메타데이터를 포함하고struct dentry디렉토리 트리에서 파일 위치를 추적합니다.
답변2
나는 그 안에서 답을 찾았다.개방형 시스템 호출에 대한 문서:
POSIX는 "열린 파일 설명"이라는 용어를 사용하여 시스템 전체의 열린 파일 테이블에 있는 항목을 나타냅니다. 다른 맥락에서 이 개체는 "열린 파일 개체", "파일 핸들", "열린 파일 테이블 항목" 또는 커널 개발자 용어로 구조 파일이라고도 합니다. 파일 설명자가 복사되면(dup(2) 또는 유사한 방법을 사용하여) 복사본은 원본 파일 설명자와 동일한 열린 파일 설명을 참조하므로 두 파일 설명자는 파일 오프셋 및 파일 상태 플래그를 공유합니다. 이러한 공유는 프로세스 간에도 발생할 수 있습니다. fork(2)를 통해 생성된 하위 프로세스는 상위 프로세스의 파일 설명자 복사본을 상속하며 이러한 복사본은 동일한 열린 파일 설명을 참조합니다. 파일의 각 open(2)은 새로운 열린 파일 설명을 생성합니다. 따라서 하나의 파일 inode는 여러 열린 파일 설명에 해당할 수 있습니다.
답변3
나는 이 질문을 주로 용어, 특히 "파일 테이블"과 관련된 것으로 해석합니다.
이전 구현을 살펴보면 시스템에 열려 있는 모든 파일 설명의 컬렉션이 배열이라는 것을 알 수 있습니다. 프로세스에 새로운 열린 파일 설명이 필요한 경우 배열에서 사용되지 않은 슬롯을 검색하고 해당 슬롯에 대한 포인터가 반환됩니다. 예를 들어 falloc하단을 참조하세요.http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/fio.c
이 시스템에서 "파일 테이블"은 시스템 전체에 적용됩니다 struct file.
오늘날 열린 파일 설명은 고정 크기 배열에서 사용되지 않은 슬롯을 선택하는 것보다 더 유연한 메커니즘을 통해 동적으로 할당됩니다. 시스템의 모든 열려 있는 파일 설명 모음은 연속 배열과 같은 설정으로 정렬될 필요가 없습니다. 따라서 각 동적 메모리 할당 풀을 "테이블"로 생각하지 않는 한 더 이상 "파일 테이블"이 없습니다.
Wikipedia 다이어그램의 "파일 테이블"은 열린 파일 설명 세트입니다. 파일 설명자는 파일 설명을 여는 포인터 배열에 대한 인덱스입니다. 열린 파일 설명은 항상 일부 배열의 숫자 인덱스가 아닌 이러한 포인터를 통해 액세스되므로 연속적인 상자 열로 그리는 것은 약간 오해의 소지가 있습니다. 그것을 "테이블"이라고 부르는 것은 이러한 오해의 소지가 있는 이미지를 강화합니다.
하지만 이는 상당히 일반적인 사용법이므로 조만간 사라질 것이라고는 예상하지 않습니다.
답변4
귀하의 요구 사항이 명확하지 않아 이해하려고 노력하고 있습니다. 하지만 내가 올바르게 이해했다면 여러 프로세스가 동일한 파일에 어떻게 쓸 수 있는지 묻는 것입니까? Linux에서는 기본적으로 파일이 프로세스에 의해 잠기지 않으며 여러 프로세스가 항상 동일한 파일에 쓸 수 있습니다. 물론 파일 형식이 손상될 위험이 있습니다. 쓰기는 한 번에 하나의 버퍼인 경향이 있습니다. (대부분의 경우 이는 전체 텍스트 줄을 의미하며 파일이 공개 로그이고 여러 프로세스가 여기에 쓰는 경우에는 잘 작동합니다.) 버퍼링된 파일을 사용할 수는 있지만 파일을 열 때 기본이 아닌 추가 옵션을 선택해야 합니다.
무작위 IO를 사용하여 열린 파일은 여러 프로세스에서 열리면 실제로 왜곡될 수 있으며 이러한 유형의 IO를 안전하게 사용하려면 파일 잠금이 필요할 수 있습니다.
또 다른 관련 질문은 프로세스가 파일에 자주 또는 전혀 쓰지 않는 경우에도 실행 중인 프로세스에 의해 파일이 열린 상태로 유지되는지 여부입니다. "삭제"하더라도 파일은 계속해서 디스크 공간을 차지합니다. 프로세스에서 사용하는 디스크 공간은 파일을 닫아 파일 핸들을 해제한 후에만 복구됩니다.
열린 파일에 대해 자세히 알아볼 수 있는 또 다른 곳은 /proc 디렉토리, 특히 /proc/PID/fd입니다. 이는 특정 PID에 대해 프로세스가 어떤 파일을 열고 있는지 확인하는 방법입니다.